Pipenv: Fully support pip options on install

[JamesRamm]

First, thanks for great project :+1:
The main thing stopping me from using it is its' support for pip install.
Currently, pipenv is parsing arguments for install and then recreating the pip argument string from them (pip_install).

This allows it to support its own options, but means pip compatibility is limited - e.g. installing in editable mode (-e) or installing from VCS.

It would be possible to support all pip install options by simply forwarding unknown options on pipenv install to pip install (http://click.pocoo.org/5/advanced/#forwarding-unknown-options). This would also mean no development required to support future pip changes.
Is that feasible?

[nateprewitt]

Hey @JamesRamm, thanks for taking the time to open this. So this seems similar to #251 which we discussed other specific options for pip install. I agree it would be nice to be able to pass some more options to the pip commands but doing that has it's own tradeoffs.

I entertained the "unknown" option when we were looking into #251 but this has a couple of issues that we didn't like. We lose command correction, so if the user types --threee instead of --three, they don't receive any feedback, it just processes the command while ignoring their argument. This can lead to unexpected/unwanted outcomes. We also aren't piping all of these commands directly to pip install, so we'd still have to write code to manually check which unknown commands are forwardable to pip.

Is there a specific option you're currently not able to use with pip install?

[JamesRamm]

@nateprewitt
I believe it is possible to separate out 'unknown' options and 'known' options using click, so you would still be able to validate pipenv specific options such as --three. The click manual has an example showing filtering out commands to be passed on directly to pythons' timeit while still processing 'known' commands:
http://click.pocoo.org/5/advanced/#forwarding-unknown-options
So basically, collect unknown arguments in its own object, process your known arguments as normal and pass the unknown ones to pip.

Pip has its own error reporting if you pass unknown stuff, so you could generally leave it to pip to catch any 'unknown to pip' options which are passed in the 'unknown to pipenv' options. I suppose you could intercept pip error messages to report them in pipenvs' style. I'd still consider it to be less work than adding pip commands on a case-by-case basis.

As for specific options, there are a few I use regularly such as 4, 5 and 6 from the examples shown here:
https://pip.pypa.io/en/latest/reference/pip_install/#examples

[nateprewitt]

I believe it is possible to separate out 'unknown' options and 'known' options using click, so you would still be able to validate pipenv specific options such as --three.

So the example I'm worried about isn't that Click won't recognize defined parameters. It's the case where use user mistypes a command and instead of being asked "Did you mean --three?", pipenv just ignores it.

As for specific options, there are a few I use regularly such as 4, 5 and 6 from the examples shown here:
https://pip.pypa.io/en/latest/reference/pip_install/#examples

All of these are currently supported by pipenv in it's current state. If you look at the documentation for Pipfile, you'll find the sytanx for specifying editable, version controlled dependencies, and extras.

The only additional features I can find that the unknown arguments problem solves are --pre, almost everything else is supported or configurable in pip.conf. I'm not completely against this but the current propositions have more negatives than positives, at least in my opinion.

[nateprewitt]

Hey @JamesRamm, I'm going to close this for now since we appear to already handle your desired use cases in Pipfile. Please feel free to reopen this is you're having problems with this functionality or have further related discussion points.

Thanks!

[JamesRamm]

:+1:

[benkuhn]

Not a huge problem, but we ran into a bit of trouble migrating to pipenv due to not being able to supply --root to pip. I'd love even something clunky like being able to pass --pip-args '--root --whatever-else' as an escape hatch.

[uranusjr]

@benkuhn All pip arguments can be specified as environment variables. You can set PIP_ROOT for --root, for example. Related documentation: https://pip.pypa.io/en/stable/user_guide/#environment-variables

[benkuhn]

Wow, thanks for the tip! Don't know how I missed that in the Pip docs :)