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.

This makes the virtualenv difficult to export to another machine. The VIRTUAL_ENV variable must be manually changed. 

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?

I propose to makes VIRTUAL_ENV eqauls to the parent folder of the directory where `activate` resides. It makes it possible to move the virtualenv and copy it to another machine with the same OS.

> 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 user-built Python 3.7), `python3` from PATH may refer to the incorrect installed version. Having a symlink to the the Python executable which built the environment (by default; `--copies` overcomes this) forces an executable.

This `python3` symlink still makes it distributable to other machines on the same platform anyway: `/usr/bin/python3` should always be available on other distributions with Python installed normally, and Windows copies the Python executable anyway AFAIK.

Across-platform is likely not going to work anyway: it's likely that your virtual environment will contain platform-specific installations of the packages, meaning they won't work on other platforms. If you just want Linux/MacOS portability, check out the Pex project.

I agree with VIRTUAL_ENV being relative however

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.

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 structured to be directory-specific.

So thanks for opening the issue, but I'm closing as not a bug.

> 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
> something else wasn't structured to be directory-specific.

You are telling about user code, not the virtualenv itself. If the user doe not write the code in such a way it's portable, it's his fault. But this should not stop people that do it right to try to port the venv if possible.

I think the modification
VIRTUAL_ENV="$(dirname "$(dirname "$(readlink -nf "$0")")")"

is very little and quite robust. Don't know how to do in fish and csh shells, but in bash and sh it works.

Well, what about the modification to VIRTUAL_ENV? I think it's little and without harm.

Changing VIRTUAL_ENV will break code, so I'm not sure if it's worth changing.

> 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.

If you're moving the virtual environment directory in Linux you'll also need to update the shebangs for the scripts/binaries

"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 good justification, but simply to make it easier to have "unofficial unsupported bonus" is not a good enough reason to upset people with requiring everyone to update their code.

Well, I repeat, not with 

#!/usr/bin/env python3

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 possibility at all to move it, so I don't know why they should be upset. 

And yes, I consider a code that depends from the path of the folder it resides a bad code.

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.

Please Mr. Cannon, can you read my last posts? I think they are not describing a mad idea, but something reasonable.

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 recreate the virtual environment as necessary and risk surprising people who expect VIRTUAL_ENV to function as it does today and has for years.

> 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 wind) Well, didn't you have software tests?

@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 cannot simply reinstall the dependencies on the VM, because it can't reach the private pypi repo.

I have not contributed to Python before, but I am happy to help with reviewing a PR with the changes that you suggested.

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, create the venv and install them using `pip install $PATH_TO_PACKAGE`