How does pipenv know the virtualenv for current project ?

[sachinjain024]

I have just setup a python project using pipenv. One thing I want to know is where does pipenv store the mapping of project directories to virtualenvs.

To be clear, I am running the following command:

sacjain-macOS:coursera-classification sacjain$ pipenv --venv
/Users/sachinjain/.local/share/virtualenvs/coursera-classification-iTBt6WsT

I checked Pipfile and Pipfile.lock, I assumed this information should be present in Pipfile but it was not there.

Q2. How can we install a specific version of package using pipenv ?

[uranusjr]

The virtualenv’s name is the project’s root directory name, plus the hash of the full path to the project root. This guarantees the name to be unique and predictable as long as you don’t move the project. (AFAICT this name generation logic is an implementation detail that should not be relied on.)

To install a specific version of a package, use the same syntax as you would with pip and requirements.txt, e.g. pipenv install django==1.11.0.

[sachinjain024]

@uranusjr This means that if I rename the directory my project's virtualenv will be lost. That's bad. It can be a common use case to rename a directory and users may fall into this and wonder how their environment stopped working.

I would suggest to fix it and make an entry into Pipfile if that's possible. Or create another .pipenv file to store such metadata in each project directory.

What do you suggest ?

Thanks for answering both the questions!

[nateprewitt]

Hey @sachinjain024, we've had a few discussions on the local metadata file but the maintainer consensus has been that pipenv won't be supporting that at this time.

The directory path identifying a project was something that was implemented early on because projects with the same name, or multiple copies of the same project, were causing accidental overwriting of environment state.

In practice, we've found far fewer people have had issues with the location being part of the environment than silently having their work overwritten. Pipenv is a deployment management tool after all, so moving the directory should be a one command fix.

[sachinjain024]

Thanks @nateprewitt. It makes sense to quickly jump to easy implementation. Suppose I rename a project at later stage then it means my environment does not exist.

So what should I do in this situation ?

1. Resetup the environment because I have Pipfile already which has the packages information so it will be easy to resetup the env.
2. Somehow rename the virtualenv directory too
3. ???

What do you suggest in this case ? Just curious in case I get in this situation in future.

[uranusjr]

You can use pew cp to easily copy the existing virtualenv, but 1. would be the more “canonical” way to do it I think.

[nateprewitt]

@sachinjain024, whenever you need to move your project directory, you should only need to run pipenv install to get back to a working state. This will create an environment for you with the new hash and reinstall everything from the lockfile identically to the previous installation it was created with.

If you find yourself doing this often, you may want to use pew rm old_project-a3de90 to cleanup.

[nateprewitt]

I wouldn't recommend using pew cp unless you're modifying the virtual environment outside of pipenv. In that case, I think we'd have to consider that a "voided warranty" scenario, because there are all sorts of changes we can't account for reliably.

[sachinjain024]

Thanks @nateprewitt @uranusjr. Closing this ticket.

This is one of the worst ideas that came out of pipenv so far. Here's why:

I work in a company, where Python is used for test automation of a lot of internal projects. One tester usually works on a dozen of those. By convention, all test code for a project lives in directory called tests. This means, that each tester now has a bunch of virtual environments all called something like ~/.local/share/virtualenvs/tests-hKjFddnZ - awesome! It is a human nature to forget to switch virtual environment, so, every few days I'm called to a different workstation because the the person at that workstation thinks that they installed the package they need, they ran pipenv install, but the imports in the code don't work. Not only that, the orphan virtual environments accumulate over time, but since all of them have nondescript names, there's no way to tell if I'm deleting environment that's not in use, or the one that's actually been used. This means that in CI, we create dozens, if not hundreds of virtual environments daily. There's no way anyone can keep track of environments that have essentially random names, and there's just too many of them, so we have to delete all of them at least once a day. We pay a huge toll in waiting times only because of this super smart decision made by pipenv and someone in our company, who decided to use it...

[jtratner]

Set `export PIPENV_VENV_IN_PROJECT=1` in your bashrc / shell configuration. (Or change your shell scripts to create a venv at $PROJECT/.venv and then pipenv will has that)

…

On Mon, Mar 19, 2018 at 6:28 AM wvxvw ***@***.***> wrote: This is one of the worst ideas that came out of pipenv so far. Here's why: I work in a company, where Python is used for test automation of a lot of internal projects. One tester usually works on a dozen of those. By convention, all test code for a project lives in directory called tests. This means, that each tester now has a bunch of virtual environments all called something like ~/.local/share/virtualenvs/tests-hKjFddnZ - awesome! It is a human nature to forget to switch virtual environment, so, every few days I'm called to a different workstation because the the person at that workstation thinks that they installed the package they need, they ran pipenv install, but the imports in the code don't work. Not only that, the orphan virtual environments accumulate over time, but since all of them have nondescript names, there's no way to tell if I'm deleting environment that's not in use, or the one that's actually been used. This means that in CI, we create dozens, if not hundreds of virtual environments daily. There's no way anyone can keep track of environments that have essentially random names, and there's just too many of them, so we have to delete all of them at least once a day. We pay a huge toll in waiting times only because of this super smart decision made by pipenv and someone in our company, who decided to use it... — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#796 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ABhjqyABdDHCB8WMm-hJwdkNptVlh8fuks5tf7KBgaJpZM4Pp3kf> .

@jtratner Then why do I need pipenv if I'm going to create virtual environment by hand?

Virtual environment is a piece of work on its own. It's lame everywhere and is broken on Windows (it assumes that on MS Windows, of all places, the default home directory is called "~"). I was hoping that if someone was to redo PIP and virtual environment, they would, you know, fix the obvious errors of their predecessors... instead, there's this mess multiplied by a layer of incompatibility.

[uranusjr]

You’re making wrong assumptions. Pipenv does not redo either virtualenv or pip. It builds on them.

@uranusjr that's a reading comprehension problem. I know very well, what pipenv does, since I spend much more time debugging its code than I'd like to. To redo virtual environment and PIP is the project's stated goal. That, instead of fixing them it decided to use them "as is" is another huge mistake on the part of pipenv, followed by using click library, and the list goes on.