Pipenv: Name of the virtualenv

[andreagrandi]

More than I issue is a question: is this https://github.com/pypa/pipenv/blob/d122401869391db4c42fd32cc5020861b8c8cd0a/pipenv/project.py#L131 the only way the virtualenv name is generated? Is there the possibility to specify the name from the command line? If not, it's a missing feature or rather a defined choice (to have it projectname+hash) ?

Thank you so much, cheers.

p.s: if there is a better place where to ask these questions, please let me know. I'd rather ask in the proper place :)

[justinmayer]

It appears to be a deliberate choice, and one that I have found vexing since it impacts other virtual environment tooling. Not to mention the visual cruft the hash adds to terminal console prompts, debug output, et cetera. 😞

[andreagrandi]

I could try and work on a PR to add this feature, but I would like to know what project leaders think about it. I don't want to code anything that goes against the "project philosophy".

Cheers

[techalchemy]

It is definitely intentional, however you can set PIPENV_VENV_IN_PROJECT to create the virtualenv in ./.venv or you can make your own virtualenv and use pipenv within that.

Out of curiosity how come you are finding it necessary to activate / run pipenv shell regularly? It is a feature that exists to be sure but it’s kind of a convenience feature, the goal is more to move away from working inside / caring about the location of the environment.

[andreagrandi]

I think having to use virtualenv separately (even if just to create the virtual environment) completely defeats the porpouse of having Pipenv which can handle both virtualenv and pip.

About the second question, I'm sure you were asking Justin, but I also always pipenv shell immediately and I was surprised by the fact it's not being activated right after the virtualenv creation.

In my usual workflow with virtualenv+pip I always activate the virtualenv because it helps me understanding that I'm working inside a virtualenv and which one so I don't risk to install packages outside the venv (yeah, I know... there is PIP_REQUIRE_VIRTUALENV but I still prefer to have the name always visible in my command prompt).

Also: very often I try things using ipython in the shell before writing the proper code in my IDE.

Last but not least, if you use Visual Studio Code (but it's true even for Sublime and probably Atom too) and you want to make sure the code completion works properly, you have to start ./code from the terminal, from a shell with the related virtualenv activated, otherwise the IDE will look in the global packages folder (not finding the library you just installed).

I reckon my workflow may be different from your and I'm absolutely questioning or judging your, but it's the one I feel more comfortable with.

A few bits here and there and pipenv could 100% substitute virtualenv+pip for me.

[techalchemy]

so I don't risk to install packages outside the venv

@andreagrandi the idea of pipenv is that rather than using pip to install things, you call pipenv install. This way you don't run the risk of accidentally installing things outside of your project virtualenv.

I still prefer to have the name always visible in my command prompt

Since it's based on where your Pipfile is, all that matters is which directory you're in, which is always visible from the command prompt, you'll already be able to tell which project pipenv install works on.

Also: very often I try things using ipython in the shell before writing the proper code in my IDE

I do this too, it's very handy. I include ptpython in all of my pipfiles in the dev-packages section. Instead of having to know the location of the virtualenv and make sure I have activated the correct one, I now offload all of this to pipenv by simply calling pipenv run ptpython, Honestly, it seems like pipenv would solve a lot of problems for you if you adopted this workflow. If you are going to change toolsets but make no modification to your usage, it's probably going to be somewhat difficult.

Last but not least, if you use Visual Studio Code (but it's true even for Sublime and probably Atom too) and you want to make sure the code completion works properly, you have to start ./code from the terminal

I use vscode as my main editor and I have never started it from the terminal. All I've done is set in my user settings file:

{
    "python.venvPath": "~/.local/share/virtualenvs", // or whatever your $WORKON_HOME setting is
}

And then in my workspace for each project:

{
    "python.pythonPath": "~/.local/share/virtualenvs/pipenv-MfOPs1lW/bin/python",
    "python.linting.flake8Enabled": true,
    "python.linting.pylintEnabled": false
}

You can for example write a script to generate a file for each project in your .vscode folder which takes the output of pipenv --venv after you've run pipenv install and puts the path to the interpreter in your settings file. Alternatively, you can ctrl+shift+p which works in vscode and sublime, not sure about atom, and type 'interpreter' and set your interpreter that way as long as you've done the first bit of telling the editor where to look.

So I understand why you need the results you need, but in most cases I think pipenv can actually make things easier for you if you'll modify the way you use it just a touch. We have a lot of areas for improvement, but to get the full advantage of switching to pipenv also requires a bit of adjustment

[andreagrandi]

Hi @techalchemy thanks for your reply. I think you make a very good point and I may need to adjust a few things before I can fully enjoy a pipenv.

@andreagrandi the idea of pipenv is that rather than using pip to install things, you call pipenv install. This way you don't run the risk of accidentally installing things outside of your project virtualenv.

This is true, but at the same time it could give me unexpected results. If I run pipenv by mistake in the wrong folder (outside of the project) I end up creating another virtualenvironment and I will have the new library in a different virtual environment.

Since it's based on where your Pipfile is, all that matters is which directory you're in, which is always visible from the command prompt, you'll already be able to tell which project pipenv install works on.

You assume that my full path is always visible, but it's not my case. Not having to worry about the full path, made me shorten it a while ago. When I'm in a folder I see this:

➜  test-pipenv

that's it! To check the full path I have to use pwd.

But I've noticed something even worse (for my usage). After activating the venv shell with pipenv shell I simply deactivated it in the old way, using deactivate. This removed the (test-pipenv-aXJBI-hV) from the command prompt but I was still inside pipenv shell because when I tried to enter again I got this:

➜  test-pipenv ls
Pipfile      Pipfile.lock
➜  test-pipenv pipenv shell
Shell for UNKNOWN_VIRTUAL_ENVIRONMENT already activated.
No action taken to avoid nested environments.
➜  test-pipenv exit
➜  test-pipenv pipenv shell
Spawning environment shell (/bin/zsh). Use 'exit' to leave.
source /Users/andrea/.virtualenvs/test-pipenv-aXJBI-hV/bin/activate
➜  test-pipenv source /Users/andrea/.virtualenvs/test-pipenv-aXJBI-hV/bin/activate
(test-pipenv-aXJBI-hV) ➜  test-pipenv

which was very confusing.

I will keep using pipenv for more time and see if benefits can beat current issues (for me).

Cheers!

[jekriske-lilly]

@techalchemy Trying to use pipenv in a multiuser environment (HPC cluster) and PIPENV_VENV_IN_PROJECT works well enough for creation, but if this variable is not set during use, pipenv isn't smart enough to realize there's a .venv directory and creates another virtual env. It completely ignores the pipfile/pipfile.lock and doesn't install any of the packages (besides pip, setuptools, and wheel).

Pipenv doesn't allow easy sharing of projects between users unless:

• The virtualenv path can be named during creation

  • Or make it local with a command line flag instead of/or in addition to the PIPENV_VENV_IN_PROJECT env var.

• The project stores the virtualenv path inside the Pipfile/Pipfile.lock or automatically detects a .venv directory.

There's no way I can have hundreds of users creating their own virtual environments and reinstalling all packages in their home directories on first use of every python app. If I enter a directory pipenv should know what and where to find everything (regardless of user.)

One or more developers might create a project but once deployed, it might be run by many users with various environment variables set, running multiple python applications at once with different dependencies. As you can see, venv in project is a major feature, without which, pipenv is practically unusable for end users who are actually running these apps.

As you said:

the goal is more to move away from working inside / caring about the location of the environment

• How can a user do this if the virtualenv with all of the compiled python packages is in a developer's home directory instead of a central location with the app?
• If the virtualenv is in the central location, how can the user do this if pipenv ignores .venv and the pipfiles?

[andreagrandi]

@jekriske-lilly are you saying that you share the .venv/ folders with everyone? If yes, I think it's quite dangerous. Some packages can be compiled (while installed) for a specific platform and architecture. Some packages compiled for OSX won't work on Linux and viceversa. This is not just how Pipenv behaves but a best practice too. You want to keep .venv/ folder in the same project folder? Fine. But it should be excluded using .gitignore.

[jekriske-lilly]

@andreagrandi everyone on a computing cluster... the platform is the same for everyone. At the moment all users share a single python installation. If there are upgrades to packages in this central installation, apps may break.
(Hence the need for virtual environments)

[techalchemy]

@andreagrandi @jekriske-lilly does #1210 help your situations?

[justinmayer]

@techalchemy: Unless I'm misunderstanding something, issue 1210 does not seem to be focused on the _name_ of the virtualenv, which is what this issue is about.

[jekriske-lilly]

@techalchemy yes and no, I can't see #1210 working unless it also unsets the variable if it was previously set in the environment.
Two scenarios are:

• It's set by the user and needs to be set by the project, works fine.
• It's set by the user and shouldn't be set within the project, it'll break.

A named virtual env that has its path stored in the pipfile.lock solves this in both cases.

Consider this, besides options, the one argument virtualenv takes is the environment path. Right now with pipenv, that core functionality is gone and instead the only possible paths are hardcoded into pipenv itself instead of allowing user choice.

[kennethreitz42]

this is not going to change any time soon

[andreagrandi]

I get from this that you are not going to accept any PR either... no problem, thanks for replying. Cheers

[jekriske-lilly]

@kennethreitz Thanks for the info, I'll make sure we steer clear.

[voronind]

After pipenv shell I have such prompt:

(cookiecutter-python-template-xKwE8jBR) dimka@homepc:~/work/projects/cookiecutter-python-template$ 

Is it OK? :+1:

[rdrey]

@dimka665 that's fine. But what I learned by reading this thread is that pipenv run <command> is really preferred over pipenv shell + <command> + exit / Ctrl-D