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

Automatically generate Pipfile.lock on install/uninstall #404

Closed
dan-passaro opened this Issue Jun 9, 2017 · 11 comments

Comments

Projects
None yet
8 participants
@dan-passaro
Copy link

dan-passaro commented Jun 9, 2017

It's not clear to me why pipenv lock is a separate command that the user must remember to invoke. This introduces something easily forgettable into the pipenv workflow which can ultimately lead to, say, committing but forgetting to add your dependencies (which is a pitfall already true of normal pip/virtualenv workflows).

It would be great to have the lockfile automatically regenerated on pipenv install and pipenv uninstall. This brings pipenv more in line with tools like Yarn and Bundler, which make it hard to get your dependency info into an inaccurate state.

E.g. running yarn add underscore will both insert underscore into package.json and add a locked version to yarn.lock. I think it's natural that pipenv install requests should add requests to the Pipfile and the new locked versions to Pipfile.lock.

@kenneth-reitz

This comment has been minimized.

Copy link
Contributor

kenneth-reitz commented Jun 9, 2017

because lock is slow

@jacebrowning

This comment has been minimized.

Copy link
Contributor

jacebrowning commented Jun 10, 2017

Couldn't install/uninstall simply add/remove a single key based on the package involved (while lock does a full reassessment of all package versions)?

@erinxocon

This comment has been minimized.

Copy link
Contributor

erinxocon commented Jun 25, 2017

@jacebrowning I don't think it could work like this since it involves messing with the dependencies from other packages. It would be best to just relock your Pipfile as all the dependencies dependencies get looked at and hashed correctly. You couldn't just add or remove one entry from the pipfile without removing it's dependencies as well.

@debo

This comment has been minimized.

Copy link

debo commented Jul 3, 2017

@erinxocon @kennethreitz while I understand lock generation is slow that's what pretty much any other tool does already, even composer in PHP and to be fair it's not that slow. I don't know python well enough yet to be able to help or contribute but maybe checking what other similar tools do to speed up the generation process might be an idea. Can I also suggest that if the lock file is present it should have priority when running pipenv install? Otherwise it kinds of defies its existence.

@Kobold

This comment has been minimized.

Copy link

Kobold commented Jul 7, 2017

Just echoing feedback as an end user that the separate lock command is surprising given what I'd expect coming from other deterministic package management solutions, and not totally foolproof.

yarn is a model example here and as I feel it, automated management of the lock file is the distinct user interface improvement of yarn over npm. You could make earlier versions of npm behave deterministically, but remembering to shrinkwrap was always a pain.

Just adding an additional voice in support of this issue. I totally understand the performance constraints, and thanks to everyone for all the work that's gone into pipenv!

@alok

This comment has been minimized.

Copy link
Contributor

alok commented Sep 2, 2017

this can be closed with 5.3.2

@nateprewitt

This comment has been minimized.

Copy link
Member

nateprewitt commented Sep 2, 2017

Thanks @alok!

@nateprewitt nateprewitt closed this Sep 2, 2017

@kenneth-reitz

This comment has been minimized.

Copy link
Contributor

kenneth-reitz commented Sep 2, 2017

\o/

@kenneth-reitz

This comment has been minimized.

Copy link
Contributor

kenneth-reitz commented Sep 2, 2017

Now that locking isn't slow, we can do this. yay!

@kenneth-reitz

This comment has been minimized.

Copy link
Contributor

kenneth-reitz commented Sep 2, 2017

That involved way too much work, but i'm happy with the results :)

@Kobold

This comment has been minimized.

Copy link

Kobold commented Nov 6, 2017

Thank you @alok and @kennethreitz for all the hard work!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment