Support Pipfiles

[jayfk]

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: pypa/pipfile#57

[gsemet]

+1. Pyup should be able to read Pipfile.lock and update versions in it.

[wdv4758h]

any update ?

[tony]

Just moved to Pipfile on a few projects. Totally forgot about pyup

[audiolion]

is there any schedule for supporting Pipfiles?

[austinmcconnell]

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.

[jayfk]

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?

[chris48s]

I'd say the usage is similar to other package managers that use a lock file like composer (or npm more recently):

• If your project is an end user-facing application, pin to a version in the Pipfile and commit the lockfile to formalise the second-order dependencies. This ensures deterministic installs across environments.
• If your project is a package, specify a range in the Pipfile and don't commit the lock file. This ensures maximum compatibility with other libraries that share dependencies.

pypa/pipenv#598

[austinmcconnell]

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.

[gsemet]

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.)

[jayfk]

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 pypa/pipfile#9 (comment).

[gsemet]

hash is optional, you may not update it (just safer)

[jayfk]

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:

• Formatting might be an issue. If there are any PRs that remove/add a lot of lines or change the Pipfiles formatting, please report them here.
• The bot won't respect ranges set in a Pipfile when updating the Pipfile.lock.
• The bot won't update the hash in Pipfile.lock.

Other than that, it should be pretty usable.

[gsemet]

I see the following error (link):

Error
Unknown Error

[edmorley]

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?

[gsemet]

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.

[si14]

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.

[djbrown]

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?