My team has switched over from pip / requirements.txt to pipenv / Pipfile, and it's mostly been smooth for us.
However, the auto-generated names for venvs that's shown in the prompt is upsetting people's workflows. They feel they're no longer meaningful as they once were.
I assume the original plan was it would adopt the name of the project directory it was in and this be meaningful, but for some environments that doesn't work.
#
Hi @funkybob, thanks for opening this issue and trying out pipenv. The plan was always to do exactly as we are currently doing, which is to create deterministic virtual environments the location of which is abstracted away from the user. If you want to manage virtualenvs yourself and only use pipenv for dependency management, you can simply activate a virtualenv before using pipenv (at your own risk, since using uninstall
will wipe the environment or you could overwrite a pipenv dependency).
The point of pipenv is to prevent users from worrying about their virtualenv locations, and in fact to remove virtualenv activation from your workflows for the most part. Most command invocation can be done using pipenv run <command>
and 'activation' so to speak is intended to be done using a pipenv subshell via pipenv shell
.
The alternative is to have your teams set PIPENV_VENV_IN_PROJECT
and it will create a .venv
directory off of the project root.
The pipenv workflow is designed to guide the user to be aware of and working in their project directory, without worrying about what the respective virtualenv is called or where it is. If you need to have hands-on management of your virtualenvs you probably want to use some other tool to create the environment, since pipenv explicitly is designed to create and manage this for you.
I think I have not explained myself clearly.
Already elsewhere in our project we must create a virtualenv in a specific place, and that is working fine.
I just wanted a way to specify a label used when updating the prompt to show which venv is in use.
Whilst the default makes sense in most cases, it's always nice to be able to override.
As for the PIPENV_VENV_IN_PROJECT env var, I use that in places, but it also means setting a somewhat global setting that I'd rather keep localised. I realise this wouldn't be as simple as making it a command line option, since pipenv would need to always know to look for .venv "just in case".
Next version of pipenv automatically will use .venv if it’s present in the
current directory (already in current master). :)
I don’t fully understand what you mean about a label. If you do something
like:
virtualenv my-customvenv-name
source my-customvenv-name/bin/activate && pipenv install
pipenv will install into the sourced virtualenv and your prompt should say
my-customvenv-name
when you source it.
On Tue, Feb 27, 2018 at 7:29 PM Curtis Maloney notifications@github.com
wrote:
I think I have not explained myself clearly.
Already elsewhere in our project we must create a virtualenv in a specific
place, and that is working fine.I just wanted a way to specify a label used when updating the prompt to
show which venv is in use.
Whilst the default makes sense in most cases, it's always nice to be able
to override.As for the PIPENV_VENV_IN_PROJECT env var, I use that in places, but it
also means setting a somewhat global setting that I'd rather keep
localised. I realise this wouldn't be as simple as making it a command line
option, since pipenv would need to always know to look for .venv "just in
case".—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/pypa/pipenv/issues/1509#issuecomment-369109754, or mute
the thread
https://github.com/notifications/unsubscribe-auth/ABhjq-AOCdaxSW5e6fVP20pZ8SEFrg01ks5tZMgigaJpZM4SVyqa
.
You know how when you activate the virtualenv, it alters your prompt to include the name of the virtualenv in it?
I want a way to control that name it shows.
I guess this is more a virtualenv feature request... but it'd be nice if I could specify it in the Pipfile.
feature request == custom prompt names upon creation.
We can do that.
it'll be via environment variable though, i don't want more cli flags.
$ PIPENV_VENV_PROMPT='(custom)' pipenv --three
Pew doesn’t support this, so changes will need to land there first.
So with this new proposed feature, will the custom prompt show up after run pipenv shell
and are in the shell?
I was actually working on something for this today (assuming its the same thing) for windows: https://github.com/Darkle/pipenv-win-batch-scripts
oh, nevermind then
@Darkle Pipenv already does if you run the shell in compatibility mode (at least on Unix shells; I don’t use shell
very often and can’t remember the behaviour on ⌘ atm), but otherwise it’s still up to the user to decide whether to display it in the prompt. Your work is still relevant (in certain situations).
@jtratner
pipenv will install into the sourced virtualenv and your prompt should say
my-customvenv-name
when you source it.
while true, it seems you would then need to keep track of and repeatedly source the virtualenv, ie for new terminals, etc. The goal should be to have stuff work transparently after initial configuration.
@kennethreitz Were you saying nevermind because of the comment from @uranusjr that it is too much work due to Pew not supporting it, or...? It's really a bummer to not be able to easily customize the name as part of the shell prompt, since that is really a basic feature for unobtrusively tracking which virtualenv you are in.
Perhaps this could be supported more easily in PIPENV_VENV_IN_PROJECT mode since the shell prompt presumably then comes from the project directory rather than the virtualenv name?
We are recently looking into purging Pew from our implementation. This would be doable once we do that. Stay tuned :)
I'm looking for this feature as well. python -m venv venv --prompt test_venv
will create a prompt anmed 'test_venv' when the venv is activated, no matter what the venv directory is named.
Care to try your hands out implementing it? The implementation should be relatively isolated, and would be a nice issue for a new contributor :)
Most helpful comment
feature request == custom prompt names upon creation.
We can do that.