use .venv

[kakulukia]

I just started using this tool, but the first thing that comes to mind: i immediately miss that my zsh can auto activate the virtualenv enymore. Why does the tool add a hash after the projects name even if there are no conflicts? my shell can load a vitualenv either with the same name or one that can be found in a .venv dir in the project root.

Automatically linking it there should not be that hard to do and saves everyone with a decent shell having to activate the virtualenv. Or is the tool doing anything special while activating the virtualenv with the shell command?

[timofurrer]

I think key here is that the intended use of pipenv is not the same as with a plain venv.

You should use pipenv shell or pipenv run to run stuff in the virtualenv instead of manually activating it and run stuff afterwards.

[kakulukia]

but whats the difference in doing so?
The key difference i found so far is the handlich of packages, but whats the difference between pipenv shell and a workon envname?

[nateprewitt]

Hey @kakulukia, you bring up some good questions here. The reason for the hash is pipenv automatically creates a virtualenv with pew out of the box which are all stored in the same place. We had issues early on where directories with the same name were causing environment collisions and accidentally affecting more than one project when a pipenv command was run. Detecting whether a collision exists is a little harder because we don't have a way to verify if a plain named repository was created for this copy of the project name or another.

If you'd prefer to have the .venv directory in your project directory, we fully support that. Using the PIPENV_VENV_IN_PROJECT environment variable will enable this functionality for you. You should be able to continue to use your zsh functionality with that approach.

As @timofurrer noted, pipenv allows the user to avoid needing to activate the environment to begin with. Both pipenv run, and if needed pipenv shell/pipenv shell -c, should provide everything the user needs to run in the project. This way the user won't need to concern themselves with which virtualenv is activated. pipenv shell is fairly analogous to virtualenvwrapper's workon but works on the project directory you're currently in.

Hopefully that helps, let us know if you have any further questions.