search

pyupio / pyup

A tool to update your project's dependencies on GitHub. Runs on pyup.io, comes with a command line interface.
https://pyup.io
MIT License
448 stars 67 forks source link

Support Pipfiles #197

Open jayfk opened 7 years ago

jayfk commented 7 years ago

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

gsemet commented 7 years ago

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

wdv4758h commented 6 years ago

any update ?

tony commented 6 years ago

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

audiolion commented 6 years ago

is there any schedule for supporting Pipfiles?

austinmcconnell commented 6 years ago

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 commented 6 years ago

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 commented 6 years ago

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

https://github.com/pypa/pipenv/issues/598

austinmcconnell commented 6 years ago

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 commented 6 years ago

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 commented 6 years ago

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.

gsemet commented 6 years ago

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

jayfk commented 6 years ago

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:

Other than that, it should be pretty usable.

gsemet commented 6 years ago

I see the following error (link):

Error
Unknown Error
edmorley commented 6 years ago

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 commented 6 years ago

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 commented 6 years ago

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 commented 3 years ago

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?