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 [email protected] 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 [email protected] 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 [email protected] 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).

[dstufft]

Well get-pip.py will have --user be the default whenever a released version of pip does, since get-pip.py is really just pip.

[techtonik]

On Thu, Jul 24, 2014 at 9:52 AM, Matt Iversen [email protected]
wrote:

The basic aim here, to me, seems to be bootstrapping the build tools
without requiring root.

Thanks. I was about to send a lengthy letter with explanations, but this
sentence nails it.

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.

https://bitbucket.org/techtonik/locally/src/tip/06.get-virtualenv.py?at=default

Done. Thanks for the hint with packages. I also encountered another bug:

if hasattr(os, 'symlink'):
    logger.info('Symlinking Python bootstrap modules')

This check is wrong. My filesystem under Linux doesn't support symlinking,
so
virtualenv crashed. That's why I've added --always-copy.

[jhermann]

Couldn't virtualenv.py download the necessary support stuff when it's not there, to a re-used cache location? I'm very much for a standard bootstrapping solution that requires Python and only Python to be there, too (i.e. use "python -c" to download the bootstrap, so no need for wget or curl either).

[techtonik]

On Sat, Jul 26, 2014 at 2:17 PM, Jürgen Hermann [email protected]
wrote:

Couldn't virtualenv.py download the necessary support stuff when it's not
there, to a re-used cache location? I'm very much for a standard
bootstrapping solution that requires Python and only Python to be there,
too (i.e. use "python -c" to download the bootstrap, so no need for wget or
curl either).

This is just what 06.get-virtualenv.py
https://bitbucket.org/techtonik/locally/src/tip/06.get-virtualenv.py?at=default
above
does, and you need to download this file with something to run it, because
it is not preinstalled.

[dstufft]

This can only work on Python 3.x because it's the only one that validates TLS.

On Jul 26, 2014, at 7:17 AM, Jürgen Hermann [email protected] wrote:

Python and only Python to be there, too (i.e. use "python -c" to download the bootstrap, so no need for wget or curl either).

[Ivoz]

This can only work on Python 3.x because it's the only one that validates TLS

Or just embed hashes of particular versions to get with that release of virtualenv.py?

[techtonik]

On Sat, Jul 26, 2014 at 8:37 PM, Matt Iversen [email protected]
wrote:

This can only work on Python 3.x because it's the only one that validates
TLS

Or just embed hashes of particular versions to get with that release of
virtualenv.py?

Again, this is just what 06.get-virtualenv.py
https://bitbucket.org/techtonik/locally/src/tip/06.get-virtualenv.py?at=default
above does.

[jedie]

I have created a experimental project, that enbed "get_pip.py" into a bootstrap file: https://github.com/jedie/bootstrap_env

See also: pypa/packaging-problems#55

[abalkin]

The ideas in issue may resolve #1042.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Just add a comment if you want to keep it open. Thank you for your contributions.