Extract the package installation features to another package

[vovimayhem]

I'm trying to use pipenv just for it's deterministic package fetching & locking for my Docker-based development envs, but I'm getting frustrated when for even the simplest task of adding a package to my project requires working with virtualenv, which is redundant and even represents an undesired/useless overhead when working with isolated containers, where it's totally OK to use system packages. For example, see how using the --system option at pipenv install blocks you from installing a package, and without the package it won't update the lock file.

How easy/complicated would it be to extract the package fetching /locking parts (the ones dealing exclusively with the Pipfile + lock) out of pipenv to a new project? (and make it a dependency for pipenv?)

IMHO although this project is inspired on others (ruby's bundler, nodejs's yarn, etc), I think this one does a bit too much to support a (totally valid) workflow, while hindering other workflows.

[vovimayhem]

I'd be happy to help (once I master python enough to code with confidence) to make this happen!

[uranusjr]

Sounds like this project is right in your alley: https://github.com/sarugaku/pipfile-cli

Feel free to contribute any features you need! (Clarification: I run that project.)

[vovimayhem]

@uranusjr Oh my! I spent like too much time looking for pipfile projects... I wonder how I missed this!

[vovimayhem]

@uranusjr although looking at the project, your'e re-vendoring some of the code in this project...

Isn't extracting the basic code from this project to a new library, then both pipenv and pipfile-cli use the same library as a dependency a bad or good idea?

[uranusjr]

@vovimayhem I assume you mean the vendored pipfile library? The situation is a little complex on this one—.

pipfile (the package) provides all basic Pipfile functionalities that all Pipfile-related projects would share. Pipenv is currently the only popular project that uses Pipfile, and has been evolving the spec quite often. Since the two projects share a few maintainers (and they are both under PyPA), we decided to simply vendors Pipfile in Pipenv for now, instead of running through the upstream patch-release-pull cycle all the time. This means that Pipenv’s copy of Pipfile is actually more developed that the official repository, and will eventually be merged upstream.

So yeah, as your worries, it is generally not a very good idea, but pipfile is an exception. If we have any problems with it, they should probably be proposed here as well.