Don't rely on pipfile_location to determine lockfile_location

[techalchemy]

We are currently relying on project.pipfile_location in order to determine lockfile_location. There are a few reasons for this, one of which is that we actually need a pipfile to exist in most cases in order to perform a comparison of the known pipfile hash which is stored in the lockfile and likely would require --ignore-pipfile to make this all work properly.

• We still probably need to raise an exception if this option isn't provided because everything else will be broken the minute you perform any other update operations. You can however install from the lockfile alone

• Alternatively, we can shim all of the pipfile references to be ok with the existence of a lockfile instead

• See also: pipenv sync fails without Pipfile present #2834 & pipenv sync unexpected behavior when Pipfile missing #1977

[techalchemy]

/cc @uranusjr @frostming @jxltom

[frostming]

I remember there is a PR there. #3386 , needs to be refined though.

[uranusjr]

But what do we rely on then, project root?

[techalchemy]

Yeah that is how Pipfile.find works which determines pipfile_location. Just not sure about what to do if the user provides a Pipfile.lock but no Pipfile. Do we need to just not generate the Pipfile in most cases? It’s likely as simple as adding Project.exists() instead of explicit checks for one or the other

If we leave things as they are and only make this one change to lockfile discovery, as soon as you pipenv install, a new Pipfile will be generated and it will be empty. If you ever add something to or or install again, it will wipe the lockfile.

[uranusjr]

I don’t think an empty Pipfile is the right answer, since that would be hilariously inconsistent to Pipfile.lock. I see two possibilities:

• Convert Pipfile.lock back to Pipfile, like how requirements.txt is converted on project init.
• Do nothing when Pipfile is not needed (i.e. for sync or install --ignore-pipfile), and hard-error (Pipfile does not exist!) in all other cases.