The --venv command-line option is confusingly named, shouldn't it be --virtualenv or --env-dir?

[Flimm]

pipenv includes an option named --venv which outputs virtualenv information:

$ pipenv --venv
/home/example/.local/share/virtualenvs/bla-534BN

This is a confusingly named command-line option. pipenv does not use venv at all, it uses virtualenv, and yet this command-line option is named after venv, not virtualenv. Both venv and virtualenv play similar roles, and so it's confusing to get one named for the other.

I propose deprecating --venv, and introducing a better named flag, maybe --virtualenv or --env-dir.

[Flimm]

Similarly, maybe the environment variable PIPENV_VENV_IN_PROJECT maybe should be renamed too.

[techalchemy]

Thanks for the feedback. Any option will be unintuitive to some people and require them to use the help command. This is not in our api for us to consume, it is there for people to consume. Thus we want people to be able to use commands that are short and intuitive and mimic standard library features.

I don’t really see this changing anytime soon. Api changes really require a reason beyond that they aren’t to your taste

[Flimm]

This is not in our api for us to consume, it is there for people to consume. Thus we want people to be able to use commands that are short and intuitive and mimic standard library features.

I agree with that. That is why I am surprised that you want to keep the command-line option incorrectly named.

Api changes really require a reason beyond that they aren’t to your taste

I have provided a reason beyond that it isn't to my taste: the command-line option is incorrectly named, and will confuse people.

If a command-line option was named --open-in-firefox, but it actually opened in Chrome, wouldn't that be confusing enough to be worth fixing? venv is in Python's standard library, it is not an obscure library that can be ignored, and it is different from virtualenv. --venv is incorrectly named, just like --open-in-firefox that uses Chrome rather than Firefox would be incorrectly named.

This matters, because Python developers already have to learn the differences between virtualenv, venv, pyenv, and pyvenv. These are similarly named but are different things, and deliberately using the name venv when when one means virtualenv is not helping any people who need to consume these tools.

[uranusjr]

There is no correctness either way here. Pipenv using virtualenv is only an implementation detail. There has already been efforts to push for a venv backend which eventually died out due to lack of interest, but you are welcomed to revive it), and it is totally possible for Pipenv to move to venv eventually. No matter what the situation is, Pipenv does not make a distinction between virtualenv and venv libraries, and users know only they are using “a virtual environment”, not virtualenv or venv. The “venv” option is simply a shorthand of “virtual environment”.

I have yet to see any confusion from the name Changing it would be a purely theoretical decision, not practical, and would require another renaming when Pipenv (eventually, after it gains enough adoption for people to contribute) moves to venv, which is practically worse than just keeping the (already okay) naming.