[issue36964] `python3 -m venv NAME`: virtualenv is not portable

Marco Sulla added the comment: The PR will probably be rejected... you can do something like this: 1. in the venv on our machine, do `pip freeze`. This gives you the whole list of installed dependencies 2. download all the packages using `pip download` 3. copy all the packages on the cloud,

[issue36964] `python3 -m venv NAME`: virtualenv is not portable

Cameron Hudson added the comment: @MarcoSulla thank you for opening this issue, it is a very necessary improvement. My use case: I install packages one machine inside VPN, which downloads from a private pypi repo. I then package this as a zip file and deploy it on a cloud-hosted VM. I

[issue36964] `python3 -m venv NAME`: virtualenv is not portable

Marco Sulla added the comment: > I don't like the idea of changing what VIRTUAL_ENV gets set to when I > believe you should recreate the virtual environment as necessary and > risk surprising people who expect VIRTUAL_ENV to function as it does > today and has for years. (Talking to the

[issue36964] `python3 -m venv NAME`: virtualenv is not portable

Change by Brett Cannon : -- nosy: -brett.cannon ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue36964] `python3 -m venv NAME`: virtualenv is not portable

Brett Cannon added the comment: Please do not add me back to the nosy list as I stand by my thinking that this feature isn't worth pursuing. I understand you feel they are reasonable, Marco, but I don't like the idea of changing what VIRTUAL_ENV gets set to when I believe you should

[issue36964] `python3 -m venv NAME`: virtualenv is not portable

Marco Sulla added the comment: Please Mr. Cannon, can you read my last posts? I think they are not describing a mad idea, but something reasonable. -- nosy: +brett.cannon ___ Python tracker

[issue36964] `python3 -m venv NAME`: virtualenv is not portable

Marco Sulla added the comment: Furthermore, if you destroy an old virtual env and recreate it with the new method, it continues to work as before, since VIRTUAL_ENV points to the same folder. We don't force to change the code if they continues to use the virtual environments as now.

[issue36964] `python3 -m venv NAME`: virtualenv is not portable

Change by Brett Cannon : -- nosy: -brett.cannon ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue36964] `python3 -m venv NAME`: virtualenv is not portable

Marco Sulla added the comment: The previous post was for Laurie Opperman "upset people with requiring everyone to update their code" I don't know why they have to be upset. Until now they can't move the folder. They want to move the folder? They have to change their code. Now they have no

[issue36964] `python3 -m venv NAME`: virtualenv is not portable

Marco Sulla added the comment: Well, I repeat, not with #!/usr/bin/env python3 -- ___ Python tracker ___ ___ Python-bugs-list

[issue36964] `python3 -m venv NAME`: virtualenv is not portable

Brett Cannon added the comment: "if you coded bad and it doesn't work, it's your fault." I disagree. Your request changes what VIRTUAL_ENV gets set to, correct? Changing it suddenly for users doesn't mean their code was bad, it means we changed something on them. Now we can do that with a

[issue36964] `python3 -m venv NAME`: virtualenv is not portable

Laurie Opperman added the comment: If you're moving the virtual environment directory in Linux you'll also need to update the shebangs for the scripts/binaries -- ___ Python tracker

[issue36964] `python3 -m venv NAME`: virtualenv is not portable

Marco Sulla added the comment: > Changing VIRTUAL_ENV will break code VIRTUAL_ENV it's the same if you don't move the venv. Moving it will be an unofficial unsupported bonus, and if you coded bad and it doesn't work, it's your fault. -- ___

[issue36964] `python3 -m venv NAME`: virtualenv is not portable

Brett Cannon added the comment: Changing VIRTUAL_ENV will break code, so I'm not sure if it's worth changing. -- ___ Python tracker ___

[issue36964] `python3 -m venv NAME`: virtualenv is not portable

Marco Sulla added the comment: Well, what about the modification to VIRTUAL_ENV? I think it's little and without harm. -- ___ Python tracker ___

[issue36964] `python3 -m venv NAME`: virtualenv is not portable

Marco Sulla added the comment: > if you have entry points installed then moving them to another > machine would break their shebang lines. Not if you port it on the same OS using, for example #!/usr/bin/env python3 > And even if you do it on your local machine there's no guarantee >

[issue36964] `python3 -m venv NAME`: virtualenv is not portable

Brett Cannon added the comment: Virtual environments are not designed to be portable. For instance, if you have entry points installed then moving them to another machine would break their shebang lines. And even if you do it on your local machine there's no guarantee something else wasn't

[issue36964] `python3 -m venv NAME`: virtualenv is not portable

Marco Sulla added the comment: Well, I didn't know `--copy`. I think I'll use it. :) What about VIRTUAL_ENV="$(dirname "$(dirname "$(readlink -nf "$0")")")"? In `bash` and in `sh` it works. -- ___ Python tracker

[issue36964] `python3 -m venv NAME`: virtualenv is not portable

Laurie Opperman added the comment: > Furthermore I do not understand why the simlink is created. I suppose that > `python3` is already on the `PATH`, so what's the purpose of simlink? On machines with multiple Python installs (eg Python 3.6 and Python 3.7, or a distributed Python 3.7 and a

[issue36964] `python3 -m venv NAME`: virtualenv is not portable

Change by SilentGhost : -- nosy: +vinay.sajip versions: +Python 3.8 -Python 3.9 ___ Python tracker ___ ___ Python-bugs-list mailing

[issue36964] `python3 -m venv NAME`: virtualenv is not portable

New submission from Marco Sulla : I'm telling about python3 -m venv VIRTUALENV_NAME, not about the virtualenv binary. Some remarks: 1. `VIRTUAL_ENV` variable in `activate` script is the absolute path of the virtualenv folder 2. A symlink to the `python3` bin of the machine is created.