Discussion: Use of the Pipenv.lock

[hdost]

If we're trying to use tox and pipenv to have a reproducible build I feel like we should be using Pipfile.lock when installing the dependencies via pipenv sync

This way when the tox builds run in CI or locally it should be reproducible and faster since the whole dependency graph does not need to be determined all over again.

The changes here I don't think are significant. I'd be willing to put together a patch, I just want to know if this is desired before I put in the effort.

[tonybaloney]

Pipfile.lock is specific to the Python version and the package dependencies.

There is a comment in the README about whether or not to check-in this file.

But considering what tox is mostly used for, running tests against multiple Python versions and/or package versions, using Pipfile.lock would break this use case.

[ms-lolo]

The way we use tox with pipenv (not with this plugin), we want to test a couple different things:

• does this package work on python verions x, y, and z?
• does the application defined by the Pipfile.lock file work as expected?

The first question is answered by ignoring the lock file because we want to simply generate a new environment with the latest versions of the dependencies defined by Pipfile. This is most useful when we're developing a library so we can ensure that our package will work when installed on someone else's environment.

However, when we're developing an application, we want to make sure our tests are running with the exact same versions of packages defined in the lock file because we just want to know that our application is going to run in production. The lock file defines what is running on production so we want a suite of tests that runs in that exact environment.

My suggestion would be to allow for both of those use cases with configuration options in the various tox environments. Right now, I am doing this by having some of my tox envs pass in --skip-lock but not in others.

[gluk-w]

We use tox to run tests for different services by CI. It is very frustrating for developers when something works locally, but breaks in CI because Pipfile.lock is ignored and new versions of dependencies are installed. It also takes much time to build dependency tree.

IMHO there should be some kind of a switch between "pipenv install" and "pipenv sync" for different use cases. Using "sync" we could make sure what we have locally will run in CI.

Thanks!

[rsj-ioki]

We use pipenv install --deploy (sync?) instead of this plugin exactly for the reasons mentioned by @gluk-w , @ms-lolo and @hdost