Support the --system flag in pipenv run

[orf]

Is your feature request related to a problem? Please describe.

When using pipenv in a docker container you can install dependencies using the --system flag. However if you use pipenv run in the docker container it will automatically create a virtualenv and there is no way to stop this - this entails installing pip and wheel inside the container, which in specific environments may not be possible or may take a long time.

Describe the solution you'd like

Provide a --system flag to pipenv run that skips the creation of a virtualenv and instead uses the system default.

[techalchemy]

I believe we have rejected this in the past because when you use --system there is no reason to use pipenv run at all — you can simply run the command.

[orf]

Having the commands defined in the Pipfile has it's advantages. We have a prod and dev command defined so our base docker image just executes pipenv run prod. This is quite nice as the commands are in a single place and anyone can get working, plus the docker image just needs to run a single command for all projects so less duplication.

Also in our case pipenv run dev executes pipenv run prod with some extra development specific arguments.

[orf]

All in all it's just a bit inconsistent. You can take advantage of the Pipfile (or specifically the Pipfile.lock) to install system dependencies, but you cannot make use of [scripts] to run commands in the system interpreter for no clear reason.

Not to mention you might have a system command in [scripts] that doesn't even depend on Python, perhaps one to build documentation with a go project. It would be nice to skip the install phase for this.

Having said that perhaps --system is a bad name for the flag, maybe --skip-virtualenv?

[techalchemy]

Yeah I agree with you. If @uranusjr agrees I can bring it up with Kenneth and see if we can find a consensus.

Out of curiosity is your pipfile usage here inspired by node-style package files?

[orf]

It's not that it's inspired by 'node-style package files' more that it's a common use case that node-style package files happen to solve in a similar way, as I'm sure other package files for other languages do as well.

It's just very convenient to use the [scripts] section to have a consistent set of commands across projects, much like I guess a makefile might give you. Not being able to run these scripts after using pipenv install --system without bootstrapping a whole virtualenv and installing some dependencies from the network is a curious/surprising limitation that should definitely at least be documented.

Also, as well as this, if you use it with a private pypi repository in the Pipfile which cannot be contacted from your production network then the initial virtualenv creation will hang for a very long time as it times out trying to install these dependencies., before it falls back to the default pypi server (if specified).

If this is accepted, and as this is blocking our adoption of pipenv completely, I'd dedicate whatever time is needed to get this through.

[uranusjr]

I am -0 on this. On one hand I can understand it is convinient to be able to use Pipfile as a script holder, but on the other hand this really feels out-of-place. On yet another hand (OK I know this is not how this expression is supposed to work) the whole --system thing is out of place anyway, so I guess I don’t really care if this is added. There really needs to be a better bare-bone tool to interact with Pipfile without jumping through virtual environment hoops (wait I actually made onet but nobody uses it).

[techalchemy]

@uranusjr we need to split requirementslib into about 3 or 4 different libraries at this point probably, I'll start the process if you can think of some names besides 'pipfile-cli' because I'm never publishing anything called that :p