Pipenv: Automatically generate Pipfile.lock on install/uninstall

[dan-passaro]

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.

[kennethreitz42]

because lock is slow

[jacebrowning]

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]

@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]

@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]

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 can be closed with 5.3.2

[nateprewitt]

Thanks @Alok!

[kennethreitz42]

\o/

[kennethreitz42]

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

[kennethreitz42]

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

[Kobold]

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