Pipenv: Only create new virtualenv when explicitly requested

[yevhen-m]

Currently I can't find a way to turn on confirmation prompt before creating a new virtualenv. I often call pipenv shell from the wrong directory and stop it right away, cause it starts to create a new environment. Then I need to remove Pipfile by hand. This is not convenient. How about adding a confirmation prompt before creating a new venv for some commands like shell or run? Or maybe a --create flag?

[cjw296]

@yevhen-m - any chance you could change the title of this issue to "only create new virtualenv when explicitly requested".

As a suggestion, "explicitly requested" may be because there's a Pipfile in the current directory or because a --create or --new or some such has been passed.

[yevhen-m]

@cjw296 thanks, that was exactly my point.

[acdha]

If nothing else, it'd be really nice if pipenv required some sort of confirmation before creating a virtualenv for a parent directory since this can be really confusing

[cjw296]

@kennethreitz - any chance you could give some background on why you've closed this ticket?

[sametmax]

I think the best practice would be to do like npm, and separate the two actions:

• pipenv init to create the virtualenv
• pipenv install to install

If you pipenv install outside of a virtualenv, we can give a warning, and look for near directories with linked virtualenvs to offer as suggestion.

Another bonus with this approach is that it makes adding option to the virtualenv creation much more clean.

E.G: doing pipenv install --python=version is very weird while pipenv init python3.6 very natural.

You can also more easily add features that are specific to env creation, such as:

• Prompting the user with a list of available Python: https://github.com/pypa/pipenv/issues/1471
• Giving a name to the project: https://github.com/pypa/pipenv/issues/1472

[kennethreitz42]

the current workflow isn't changing, it's designed intentionally.

init was the original design, and it was removed based on user feedback.

[sametmax]

In that case considering adding a prompt (#1471) is an nice alternative. I have at least 6 occurrences of wrongly created virtualenv in the last 3 weeks among my student. And I added one myself because I was tired.

[kennethreitz42]

not happening

[sametmax]

Ok, let's find another way to make that problem not occur then. What do you suggest ?

[kennethreitz42]

i suggest you use other software if you're unhappy with the way this software is designed

[sametmax]

Well, you said that when I suggested months and months ago we should add an option to choose the python version precisely instead of just --tree/--two. You said 'never', and you changed your mind apparently. But I recall you were less rude at the time.

Actually I recall a humble kenneth I've watched at conferences talking about love and help, and offering explanation for rejection or requesting PR, not telling people to go to hell.

But maybe you're having a bad day.

[yevhen-m]

@kennethreitz didn't expect such an attitude from a human.

[kennethreitz42]

You're complaining about the more core design feature of the package. Please don't.

[sametmax]

Alright. Sorry about that. You have a lot of work and there is no need to eat more of your energy.

Thanks for taking the time to answer the issue anyway.

[hwine]

previously @kennethreitz wrote:

init was the original design, and it was removed based on user feedback.

It sounds as if the user base may be changing from "early adopters" to "typical users".

I never thought I'd say this, but _git got this UX right_ (well, all VCS systems, actually). In most workflows, it is an extremely rare event to create a new pipenv environment. About as often as creating a new repository. Not having a way to express user intention, either by a different command (init), or an option (--create) can lead to confusing behavior for newcomers to the tool.

Would you be open to a PR that cleanly implemented a way for users to express their intention, assuming it did not break the core architecture?

[simonwiles]

It frustrates the hell out of me, too, when I accidentally run pipenv from the wrong folder. In lieu of a proper solution, I've added this to my shell RC file:

function pipenv() { python3 -m pipenv --venv 1> /dev/null && python3 -m pipenv "$@"; }

It could no doubt be improved, but I find that creating a new environment is uncommon enough that I don't mind typing python3 -m pipenv sync ... or whatever. It's not something you can easily offer when teaching students either. But it improves my life a tiny bit, and it may help others.