Open jayfk opened 7 years ago
+1. Pyup should be able to read Pipfile.lock
and update versions in it.
any update ?
Just moved to Pipfile on a few projects. Totally forgot about pyup
is there any schedule for supporting Pipfiles?
I'll chime in as another who would love pipfile support. They're fantastic! I'm planning on switching all my personal projects to use pipfiles.
How exactly are you currently using pipenv in your projects?
Are you pinning your dependencies in your Pipfile
? Are you committing Pipfile.lock
to git? Best practices?
I'd say the usage is similar to other package managers that use a lock file like composer (or npm more recently):
My usage is slightly different for applications, but not my much. I don't pin versions in the Pipfile (I use "*" to match all), but I do commit the lockfile. That way I get the same deterministic installs across environments, but it's also easy to upgrade all packages and second-order dependencies with pipenv update
.
I first learned about this "requirements-to-freeze" design philosophy in an article on Kenneth Reitz website here and adapted it to pipfiles.
I agree with what @chris48s said regarding pipfiles in packages.
My usage is slightly different for applications, but not my much. I don't pin versions in the Pipfile (I use "*" to match all), but I do commit the lockfile That's is the standard way of using
Pipfile
. you lock in Pipfile only in case of big imcompatibility between 2 modules. But it is always best to work by range and operators (>=, <=,...) in pipfile.
I also recommend to commit the lock file for application (you want to freeze all the dependencies so when user installs the python application, it installs exactly what the developer validated). For libs, you don't commit the lock files. I also generate manually the requirements.txt
so external services that does not support Pipfile yet can still work (using pipenv-to-requirements.)
Okay, I'm currently working on basic support for Pipfiles. Still need to write some tests, but it's looking good so far.
One thing that will be horrible to support though is the combination pinned Pipfile
+ commited Pipfile.lock
. This combination will force the bot to update the hash in Pipfile.lock
on every update, resulting in merge conflicts if there's more than one update available.
I wrote about this potential issue in https://github.com/pypa/pipfile/issues/9#event-1232401690.
hash is optional, you may not update it (just safer)
I've just pushed experimental support for pipenv to pyup.io. If you are using the CLI, you'll need to install from master.
To enable it, simply add your Pipfiles to your .pyup.yml
:
requirements:
- Pipfile
- Pipfile.lock
The update should cover most of pipenvs workflows, but there are some caveats:
Pipfile
when updating the Pipfile.lock
.Pipfile.lock
.Other than that, it should be pretty usable.
Thank you for your work on this!
The bot won't respect ranges set in a Pipfile when updating the Pipfile.lock.
Unfortunately this is a blocker for us, since we have a few deps that have to be held back (eg Django<2
until we finish our Python 3 migration).
The bot won't update the hash in Pipfile.lock.
Is it just the overall lockfile hash that remains unchanged, or the per-package hashes? With our current requirements files, we make use of pip's hash-checking mode, so would need the latter.
What impact does not updating the overall lockfile hash have?
hash is not that mandatory (it's the pypi server that exposes these hash). They however allow verification of integrity of the retrieve packet.
For the range/freeze syntax issue, it is kind of mandatory, limiting for any reason some version is perfectly legit, especially when need to banish a corrupted or vulnerable version.
Hey @jayfk! First of all, thanks for your great work! is there a chance to see full hash & range support in pyup in a near future? No pressure, just wondering so we can plan things around.
For me Pipfile
and Pipfile.lock
are analyzed correctly with correct hash values.
Also there weren't any comments/complaints in years.
@jayfk @rafaelpivato maybe close this feature request?
Pipfiles are on its way to be a thing.
It'd great if pyup could support this as soon as the internal API is stable: https://github.com/pypa/pipfile/pull/57