upload virtualenv.py to https://bootstrap.pypa.io/

[techtonik]

wget https://bootstrap.pypa.io/virtualenv.py is much easier than

open browser to lookup X.X

$ curl -O https://pypi.python.org/packages/source/v/virtualenv/virtualenv-X.X.tar.gz
$ tar xvfz virtualenv-X.X.tar.gz
$ cd virtualenv-X.X
$ python virtualenv.py myVE

From use locally from source at https://virtualenv.pypa.io/en/latest/virtualenv.html#installation

[pfmoore]

The problem is that virtualenv.py doesn't work standalone. You need the virtualenv_support directory as well, which is what is in the tarfile alongside virtualenv.py (there's some other stuff too, but that's just for publishing convenience of only having to create one tarfile rather than 2 distinct ones).

[techtonik]

I was able to make it work with this:

 wget https://raw.githubusercontent.com/pypa/virtualenv/1.11.X/virtualenv.py
 wget https://bootstrap.pypa.io/get-pip.py
 mv docbuilder{,.old}

 python virtualenv.py docbuilder --clear --no-setuptools --system-site-packages
 . docbuilder/bin/activate
 python get-pip.py
 pip install sphinx sphinxcontrib-cheeseshop

[pfmoore]

Yeah, that works. At that point it's not really much simpler than the recommended approach, though ;-)

[techtonik]

That's why this issue exists. =)

[pfmoore]

Sorry, I don't follow. The recommended approach is simpler, what are you proposing? Obviously not that your alternative (more complex) approach be used instead. Do you have a suggestion for simplifying the install process? The title of the issue implies that you think having virtualenv.py available for direct download will help, but I don't see how. Can you clarify?

[techtonik]

I propose this:

wget https://bootstrap.pypa.io/virtualenv.py
# ^^^ or use your browser
python virtualenv.py newenv

It is the most simple way to bootstrap everything.

It will help to get custom Python installation on systems with no sudo and no write access to system-wide site-packages. It will also work on Windows, where tar is unavailable.

[Ivoz]

It is also possible to use get-pip.py with the --user command, thus requiring no root privileges.

[techtonik]

And where it will install pip into if there is no virtualenv yet?

[dstufft]

Into the user site packages if there is a --user

On Jul 23, 2014, at 3:04 PM, anatoly techtonik notifications@github.com wrote:

And where it will install pip into if there is no virtualenv yet?

—
Reply to this email directly or view it on GitHub.

[pfmoore]

I propose this:

wget https://bootstrap.pypa.io/virtualenv.py
# ^^^ or use your browser
python virtualenv.py newenv

It is the most simple way to bootstrap everything.

But it won't work. virtualenv.py doesn't work standalone (and can't be easily made to, if that's your implication - I did a lot of work trying to build a single-file virtualenv, and couldn't make it work - obviously PRs accepted if anyone else manages, though).

You can use virtualenv.py standalone if you use the --no-setuptools flag, but it's hard to explain precisely why that's OK in the docs, hence we don't document it as supported (we're not likely to break it, on the other hand, so if it suits you then you're OK to use it). And you still have to bootstrap pip into the virtualenv.

Sorry if I'm not following your proposal.

I assume you know this, but https://raw.githubusercontent.com/pypa/virtualenv/master/virtualenv.py is the current master release of virtualenv, so that would be the same as the https://bootstrap.pypa.io/virtualenv.py you propose. So your proposal is essentially to have a "nicer" URL for that file, is that right? If so, then I'm -1 on that, as I don't want to have to provide support for people who try to use it without understanding the limitations.

There is a good reason the documentation says, in a highlighted note:

The virtualenv.py script is not supported if run without the necessary pip/setuptools/virtualenv
distributions available locally. All of the installation methods above include a virtualenv_support
directory alongside virtualenv.py which contains a complete set of pip and setuptools distributions,
and so are fully supported.

[dstufft]

Forgive me if I'm wrong, but couldn't we just embed the wheel files it virtualenv.py and as a fallback if we can't find any restore them to a temp location?

On Jul 23, 2014, at 3:59 PM, Paul Moore notifications@github.com wrote:

But it won't work. virtualenv.py doesn't work standalone (and can't be easily made to, if that's your implication - I did a lot of work trying to build a single-file virtualenv, and couldn't make it work - obviously PRs accepted if anyone else manages, though).

[pfmoore]

@dstufft Yes, that would work. But unpacking takes a lot of time, and having virtualenv be fast is important too (think something like tox that creates lots of virtualenvs). Using the embedded versions as a fallback gives the speed back at the cost of size (the main distribution doubles in size) or maintenance (we maintain two flavours of virtualenv.py)..

Basically lots of trade-offs, and honestly I don't see a single-file virtualenv as being so important as to warrant the effort. YMMV, of course. Anyone who wants to try it out can build their own custom virtualenv with the wheels embedded - see https://virtualenv.pypa.io/en/latest/virtualenv.html#creating-your-own-bootstrap-scripts for the details.

[dstufft]

Yea sure. I'm on the fence about if it's worth it or not :)

On Jul 23, 2014, at 4:59 PM, Paul Moore notifications@github.com wrote:

@dstufft Yes, that would work. But unpacking takes a lot of time, and having virtualenv be fast is important too (think something like tox that creates lots of virtualenvs). Using the embedded versions as a fallback gives the speed back at the cost of size (the main distribution doubles in size) or maintenance (we maintain two flavours of virtualenv.py)..

Basically lots of trade-offs, and honestly I don't see a single-file virtualenv as being so important as to warrant the effort. YMMV, of course. Anyone who wants to try it out can build their own custom virtualenv with the wheels embedded - see https://virtualenv.pypa.io/en/latest/virtualenv.html#creating-your-own-bootstrap-scripts for the details.

—
Reply to this email directly or view it on GitHub.

[pfmoore]

Yea sure. I'm on the fence about if it's worth it or not :)

Personally, I wouldn't object to someone making a PR, as long as the current setup remained the default (i.e., the wheels on PyPI remained the same size and were the unbundled format). I don't think it's likely anyone will bother, though.

[Ivoz]

The basic aim in this issue, to me, seems to be allowing bootstrapping the build tools without requiring root.

The ostensible problem being that currently the tools always need some extra flags provided in order to achieve this, that aren't exactly well-advertised (at least for this purpose).

Yet another workaround is to download wheels of pip and setuptool to a directory, and then run virtualenv.py with the --extra-search-dir=<that_directory> flag.

Honestly someone could easily write a script to do all that rather easily, that encompasses any of these methods, but what we need to find is the best / most easily supported method.

Since AFAIK the @pypa's sentiment is still making the --user functionality a default, I think it could be workable to add that default also to the get-pip.py script, allowing it to work without root and thereafter simply allowing pip install virtualenv as well. It's not the quickest route like writing a script is but it contributes the most overall improvement to the ecosystem experience (at least IMHO).