Update installing.rst #1081
Update installing.rst #1081
Conversation
Mostly prompted by pypa#1079, but also addresses a few concerns about promoting good security practices as discussed on distutils-sig over the past few months :)
| @@ -40,18 +40,66 @@ installation. For instance:: | |||
|
|
|||
| When used in this manner, pip will only affect the active virtual environment. | |||
|
|
|||
| See the `virtualenv installation instructions <http://www.virtualenv.org/en/latest/#installation>`_. | |||
| The `virtualenv installation instructions <http://www.virtualenv.org/en/latest/#installation>`_ suggest | |||
| using pip to install it if you don't already have it, though, so if the first command above doesn't work | |||
There was a problem hiding this comment.
I don't follow this sentence. "though, so"?
the virtualenv instructions offer 3 ways to use or install virtualenv. one way is using pip and it says "To install globally with pip (if you have pip 1.3 or greater installed globally)"
There was a problem hiding this comment.
The only instructions virtualenv offers that are suitable for a new user
are the ones based on pip, so there's really no reason to reference them at
all. On Windows, none of the shell commands will work, and on Linux and Mac
OS X, beginners have no justification for installing anything into their
system Python, because they will break it and have much bigger things to
worry about than how to bootstrap Python's package installation tools.
There was a problem hiding this comment.
On 24 July 2013 10:38, ncoghlan [email protected] wrote:
The only instructions virtualenv offers that are suitable for a new user
are the ones based on pip, so there's really no reason to reference them at
all. On Windows, none of the shell commands will work, and on Linux and Mac
OS X, beginners have no justification for installing anything into their
system Python, because they will break it and have much bigger things to
worry about than how to bootstrap Python's package installation tools.
I'd suggest a pull request for virtualenv, then. Add a get-virtualenv.py
script that puts just virtualenv.py and the virtualenv_support directory
somewhere, and update the instructions to say use that, put the target
location on PATH, and use that standalone virtualenv.
That would be my preferred "how to bootstrap virtualenv" solution. It's
what I do manually and it works very well. It's only missing an automated
bootstrap script to make it newcomer-friendly.
| ~~~~~ | ||
|
|
||
| On Linux, pip and virtualenv will generally be available through the system package manager. | ||
| Recent versions of common desktop Linux distributions include suitably recent versions of |
There was a problem hiding this comment.
btw, I recall now that we added and then removed the distro instructions during the 1.3 release.
1.3 had the ssl fixes, and we knew the distros would be behind, so recommending it didn't make sense.
There was a problem hiding this comment.
Fedora at least has caught up now (system pip is 1.3.1), and because it's a security issue, I'd be surprised if Ubuntu or Debian hadn't upgraded as well.
There was a problem hiding this comment.
These are the appropriate instructions, as I best understand them, for installing pip and virtualenv globally on Linux, Mac OS X and Windows. I never knew an OS could make it so difficult to save a file with the name you want... Even if we do a "get-virtualenv.py" script instead (which is a good idea), the challenges of downloading Python scripts with IE and ensuring they have the right name will still apply. I think we also want to unconditionally recommend installing the Python Launcher for anyone that is using 2.7 on Windows rather than 3.3+
|
I no longer think this a good change (the stuff Paul and Jannis are talking about regarding instructions for boostrapping virtualenv sounds better), but I wanted to share the horror that is working through the Windows bootstrapping when Internet Explorer to do the download and Windows Explorer flipped back to its default "Hide file extensions" setting :) |
|
The best answer of all might actually be a very basic Windows installer for virtualenv. But given that by promoting the idea of an initial install of virtualenv and then leave the system Python well alone we're in essence arguing against the sort of principles that bundling pip with Python is working on, I don't want to start down that route until the contradiction is resolved and we have a unified view on the matter. (I could probably design quite a nice virtualenv installer and GUI interface if I felt it was worth it - but we're back to diverging experiences between Unix and Windows which I don't see as a good thing because it encourages the Unix developers to ignore Windows...) |
|
I'm beginning to agree with you - the "use pip to manage the contents of virtual environments" and "use the system installer (whether yum, apt, MSI, etc) to manage system installations" approach is simple and clean. It's only attempting to use pip with an existing system installation that gets ugly. We're working on a separate PEP that could form the basis of an ability to selectively share modules between virtual environments (the "*.ref" file idea) and between virtual environments and the system environment, which would make it easier to handle packages with complex dependencies that wheels currently can't cover (or we can just leave that whole area to the hashdist/conda folks) That suggests to me that a more suitable goal for 3.4 may be "ensure pyvenv provides an up-to-date pip in the virtual environments it creates" rather than "provide pip by default". And then, rather than bootstrapping virtualenv as such, we may want to tweak the Python Launcher for Windows to install a "pyvenv" equivalent, just as it already provides "py" and "pyw". |
lock
bot
added
the
auto-locked
Mostly prompted by #1079, but also addresses a few concerns about promoting good security practices as discussed on distutils-sig over the past few months :)