Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

use pipenv $cmd --keep-outdated instead of locking all the dependencies in the Pipfile itself #233

Closed
heartsucker opened this issue Jan 28, 2019 · 0 comments
Labels

Comments

@heartsucker
Copy link
Contributor

Currently our Pipfile uses notation like so:

[dependencies]
dep1 = "==1.2.3"
dep2 = "==4.5.6"

We manually add all our dependencies and their transitive dependencies so that when a new dev or CI does pipen install, pipenv won't attempt to update outdated dependencies causing unexpected updates or drift between the dev env at the time of development to the CI env at time of test runs.

This same effect can be achieved more simply by using pipenv install --keep-outdated.

In our current method, we also can't easily do pipenv install foo because we have to go into Pipfile and add all transitive dependencies when we want to add a single package. Additionally, this will get us into dependency hell at some point in the future because by pinning every version of every package, we lose the ability to intelligently resolve dependency versions and we will have to manually update many packages.

The proposal is to add developer notes to tell people to use --keep-outdated and then add this flag to CI. We would go back to using dep_x = "*" in the Pipfile. In cases where we need to be above a certain version for a dependency or transitive dependency, we should explicitly comment the reasoning like so:

[dependencies]
...
# this transitive dependency needs to be above 1.2.3 because of CVE-2019-1312
requests = ">=1.2.3"
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

1 participant