feature: exclude package from locking (or explicitly lock to "master" ref)

[matejcik]

We're using pipenv in the following scenario: our main application has a Pipfile with several python libraries, including our testing library. This is used in Travis.

We want to be able to lock all "regular" dependencies, as well as the testing library's dependencies. At the same time, we always want to use testing library from git master.
This is because we always want to get updated features and testcases from the testing library, but we used to experience problems when the dependencies had conflicts in versions with the "regular" dependencies or with Python packages provided by Travis. Admittedly, a little strange scenario.
There are some potential failure modes when the library grows a dependency or changes a version, but we would learn about this from a failed Travis run and update Pipfile when appropriate.

This was working fine for us when we locked to "ref": "master" in Pipfile.lock. But at some point, this stopped working - pipenv will now lock to an explicit commit.
Admittedly, that makes much more sense! But on the other hand, I don't see a way to support our scenario anymore. For now, my solution is to edit Pipfile manually and put back "ref": "master" where appropriate. It would be nice if there was an option to either tell pipenv to do this by itself, or an option to mark a dependency as "should not be locked", without this affecting its dependencies.

[uranusjr]

This sounds like a typical use case for editable installations. The idea is that since you don’t want Pipenv to manage the source for you, you can manage (clone, fetch, pull, etc.) yourself, and add the on-disk source into Pipfile as an editable. This would tell Pipenv to simply keep a reference to the package (specified by path), and leave you to update whatever is in that path.

[matejcik]

Sounds reasonable, and we are using editable - otherwise dependencies would not be locked. Maybe this is a regression then?

The following line in Pipfile:

trezor = {git = "https://github.com/trezor/python-trezor", editable = true, ref = "master"}

corresponds to this Pipfile.lock entry after pipenv lock:

         "trezor": {
             "editable": true,
             "git": "https://github.com/trezor/python-trezor",
             "ref": "305cb55d022b8d4aaf0a5cc6465513ead95625a5"
         },

This used to read "ref": "master", and manually specifying that in the lockfile seems to work fine -- except, of course, it's overwritten with each pipenv lock.

[uranusjr]

Maybe we are treating ref wrong here. Obviously we should lock ref to the exact commit, but maybe not for editable? Or maybe we should remove the editable marker? /cc @techalchemy

(Side note, editable from a remote source is quite tedious to manage from my experience. Do a local checkout and use local path for editables instead, it would be much easier to work with.)

[techalchemy]

As a side-note, all editable installs for pip and pipenv are handled as described, they are cloned locally and checked out to the specified ref...

And this is the core difference between pipenv and using requirements.txt. Pipfiles have the unpinned reference, but when you lock your environment your lockfile needs to be idempotent, i.e. when you hand it to another user/machine it needs to produce the same environment. So the lockfile will always point to a hash. We used to not resolve these, but that was not a feature, it was because we didn't fully implement the SHA lookup.

The behavior described needs to be handled in the Pipfile, since that is how environments are resolved in the first place. Just put specific hashes or tags for the libraries you want, and leave the others unpinned. Then enjoy updates from your testing repo.