Pipenv will pollute my filesystem with Pipfiles

[gzagatti]

Is your feature request related to a problem? Please describe.

We have started using pipenv in our project and its great. But it has a tendency to pollute my filesystem with Pipfiles if I do not pay close attention to where I am issuing my commands.

If I am in a directory whose parents do not have Pipfiles, pipenv will simply create a new one no matter what command I issue. This is contrary to what I would expect and definitely contrary to other tools do such as git.

Describe the solution you'd like

For instance git will not start a git repo because I simply issued git status on a non-tracked directory, rather it issues an error:

fatal: not a git repository (or any of the parent directories): .git

Now I would expect pipenv to do something similar and only create a Pipfile once I initialise a given repository.

Second and related to the above problem, git has a very useful option git -C <path> which will run as if git was started in path instead of the current working directory. Although pipenv has the PIPENV_PIPFILE, it is not as useful and concise as -C. See a related discussion about git in here.

[techalchemy]

This has come up enough that I think we can run this up the chain a bit again; the current behavior was a design decision and we have been hesitant to revisit it, This has caused some significant confusion lately though, so perhaps we can discuss again -- would love more feedback

[alexgmin]

Commands only should create a Pipfile when it makes sense to use that command as the first one you would do on a new environment.

pipenv sync fails if a Pipfile.lock doesn't exist, because it wouldn't make sense to use pipenv sync to create a Pipfile.lock, so the same logic should apply to Pipfile.

Right now, if you do pipenv lock in new directory:

1. Creates a new environment
2. Creates a new Pipfile without any packages
3. Creates a new Pipfile.lock based on the previous Pipfile, so the only thing inside will the metadata.
   

pipenv uninstall <package> is even more fun.

A final example, Composer only creates a composer.json with composer init, composer create-project or composer require <package>. Other commands that depend on the existence of the composer.json file will fail.

[techalchemy]

Commands only should create a Pipfile when it makes sense to use that command as the first one you would do on a new environment.

Agreed, but dumping a pile of complaints under a generic issue heading is actually not going to be helpful for tracking anything or making progress on this stuff.

If you want to see specific changes it would be most helpful to see these opened separately (because we have discussed a bunch of them and while I agree with you Kenneth hasn't always historically, so we will need to get this all organized)

So I would say to both of you: I hear your issues, they are definitely valid, and I'd love to discuss them, but for example right now I'm triaging and it's nearly impossible to triage this quickly because it's not broken out/focused/summarized so that would be the best approach.

[alexgmin]

I didn't want to appear to dump a pile of complaints, I just wanted to provide some feedback, although I might have gone a bit overboard with the examples.

There are 3 possible behaviors I can think for a command that needs a Pipfile when there's no Pipfile.

1. Create a Pipfile and do whatever the command does.
2. Raise an error about the missing Pipfile, like pipenv --where does currently.
3. Don't create a Pipfile but work normally as it there was one. For example, pipenv graph would return nothing. I don't know if there's a command that currently works like this.

I'm not sure how this should be focused. Maybe an issue for every command with a behavior that should be revised?

[uranusjr]

A good way to approach this would be to lay out stages a project should go through from uninitialised (say, a fresh git clone) to fully ready to be executed. Each command can then be inspected from this perspective, to compile a table of what each should be doing if used at a given stage, and what stage the command should take the project into.