Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add an option to propagate --always-copy to virtualenv #1929

Closed
1 of 3 tasks
naufraghi opened this issue Apr 6, 2018 · 10 comments
Closed
1 of 3 tasks

Add an option to propagate --always-copy to virtualenv #1929

naufraghi opened this issue Apr 6, 2018 · 10 comments

Comments

@naufraghi
Copy link

naufraghi commented Apr 6, 2018

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
Copy link
Author

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
Copy link
Member

uranusjr commented Apr 6, 2018

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
Copy link
Member

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
Copy link
Member

uranusjr commented Apr 7, 2018

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
Copy link
Author

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
Copy link
Member

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
Copy link
Author

Just to avoid some more search:

env VIRTUALENV_ALWAYS_COPY=1 pipenv install

now does the trick.

@uranusjr
Copy link
Member

uranusjr commented Aug 3, 2018

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

uranusjr added a commit to sarugaku/virtenv that referenced this issue Aug 3, 2018
According to pypa/pipenv#1929 and pypa/pipenv#2084, this is an
environment variable to control virtualenv behaviour...although I cannot
find any reference to this claim. Implementing it for now (but not in
master until I can confirm this).
@naufraghi
Copy link
Author

naufraghi commented Aug 3, 2018

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

opnfv-github pushed a commit to opnfv/fuel that referenced this issue Sep 22, 2018
pipenv depends on pip, which conflicts with some distro versions of
pip, see bug [1].

While at it, workaround lib64 issues on CentOS by passing
`--always-copy` when creating the venv [2].

[1] pyenv/pyenv#1141
[2] pypa/pipenv#1929

Change-Id: I6af1a5fdbe8d37f75ab8b09b050449ad432191ad
Signed-off-by: Alexandru Avadanii <Alexandru.Avadanii@enea.com>
opnfv-github pushed a commit to opnfv/opnfvdocs that referenced this issue Sep 22, 2018
* Update docs/submodules/fuel from branch 'master'
  - [build] Use python -m pip workaround
    
    pipenv depends on pip, which conflicts with some distro versions of
    pip, see bug [1].
    
    While at it, workaround lib64 issues on CentOS by passing
    `--always-copy` when creating the venv [2].
    
    [1] pyenv/pyenv#1141
    [2] pypa/pipenv#1929
    
    Change-Id: I6af1a5fdbe8d37f75ab8b09b050449ad432191ad
    Signed-off-by: Alexandru Avadanii <Alexandru.Avadanii@enea.com>
opnfv-github pushed a commit to opnfv/fuel that referenced this issue Sep 25, 2018
pipenv depends on pip, which conflicts with some distro versions of
pip, see bug [1].

While at it, workaround lib64 issues on CentOS by passing
`--always-copy` when creating the venv [2].

[1] pyenv/pyenv#1141
[2] pypa/pipenv#1929

Change-Id: I6af1a5fdbe8d37f75ab8b09b050449ad432191ad
Signed-off-by: Alexandru Avadanii <Alexandru.Avadanii@enea.com>
(cherry picked from commit 54164b8)
@lucidyan
Copy link

lucidyan commented Apr 6, 2020

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants