pypa/pipenv

Add an option to propagate `--always-copy` to `virtualenv`

naufraghi opened this issue · 10 comments

naufraghi commented

Some packages (sip from PyQt in my case), are installing some header files in the virtualenv, currently the include/ folder is symlinked to the system non-nt one, and so non writable.

The virtualenv script offers the --always-copy option (active by default on nt systems) to copy all the files.

The pew script by default forwards all the unknown arguments to virtualenv.

I have the local patch working because I'd like to use pipenv in my project.

NOTE: venv has a different argument, --symlinks / --copies, with the same use, but pew currently uses virtualenv.

  • add --always-copy option to pipenv install
  • add PIPENV_ALWAYS_COPY env var
  • add tests
naufraghi commented

It's fair enough to know that the suggested solution to this use case is to use the --system option and a prebuild virtualenv.

uranusjr commented

Considering this only matters during env creation, I don’t think it’s a good idea to implement it as an option (yes I know the same can be said to --python etc., but they are regrettably already there). An environment variable is likely the way to go.

techalchemy commented

Hmm always copy is different from using global site packages right? So if you didn’t do it at env creation you couldn’t just toggle it on? From an api standpoint we’d want to call this something else since calling a cli flag —always-x when you have to pass it in every time you make an env isn’t great. I like the environment approach

uranusjr commented

IIRC --always-copy means that executables and libraries are copied from the host installation instead of symlinked.

By default, executables are symlinked on POSIX, and copied on Windows, because Windows symlinks are next to useless. The flag forces virtualenv to copy everything on POSIX as well. I don’t know what the use case is (never used it myself).

naufraghi commented

The use case was this error installing Python sip module from sources (non the dev part is not pip installable, code generator, header files, distutils extension):

cp -f /home/naufraghi/Documents/src/sip-4.19.3/siplib/sip.h /home/naufraghi/.local/share/virtualenvs/geo2d-OyxkdF0Z/include/python3.6m/sip.h
cp: cannot remove '/home/naufraghi/.local/share/virtualenvs/geo2d-OyxkdF0Z/include/python3.6m/sip.h': Permission denied
make[1]: *** [Makefile:44: install] Error 1

So, wrapping up with the questions:

  • @uranusjr this only matters during the env creation, the option can easy a bit a CI setup (even env only)
  • @techalchemy --system can in fact use the current virtualenv, that one can create manually with the --always-copy option,
  • @uranusjr exacly, the code has an explicit if os.name == 'nt' to chose the default, the use case is to easy a non standard package install inside the virtualenv

Having tried both, I think the effort to open the way for this option is not worth the value it offers. The --system option is good enough as solution for the custom virtualenv needs.

I can close the Issue, but, if there is some interest in the env variable only flag, I have an half done work I can contribute and complete till merged.

techalchemy commented

Okay, I'd say lets just leave it alone for now. Thanks for looking into this and for being thorough, it's a big help!

naufraghi commented

Just to avoid some more search:

env VIRTUALENV_ALWAYS_COPY=1 pipenv install

now does the trick.

  • 👍2
  • ❤️1
uranusjr commented

@naufraghi Where do you find the magic command? I was thinking about writing it into the documentation, but cannot find it being used anywhere in Pew, virtualenv, and Pipenv 🤔🤔🤔

naufraghi commented

I found the snippet in the linked issue about Vagrant 🤔 🤷‍♂️ and it works without touching pipenv

lucidyan commented

If someone struggling with this nowadays, I found the bug in newer version of virtualenv. You should use alias instead of VIRTUALENV_ALWAYS_COPY:

env VIRTUALENV_COPIES=1 pipenv install

More information about flags here:
https://virtualenv.pypa.io/en/latest/cli_interface.html#environment-variables

Virtualenv issue:
pypa/virtualenv#1761

  • 👍1