On 20 August 2013 11:25, Oscar Benjamin <oscar.j.benja...@gmail.com> wrote:
> On 20 August 2013 09:51, Paul Moore <p.f.mo...@gmail.com> wrote: > > 1. Will the bundled pip go into the system site-packages or the user > > site-packages? Does this depend on whether the user selects "install for > all > > users" or "install for just me"? > > If you have get-pip then why not choose at that point whether you want > to install for the system or for all users e.g.: 'py -3.4 -m get-pip > --user' (or perhaps reverse the default)? > That's not how get-pip is being proposed. It will run automatically on installation of Python. If it were manually run, *and* if a --user flag was included, then you would be correct. > 2. If pip goes into system site-packages, what happens with the > uninstaller? > > It doesn't know about pip, so it won't uninstall Python cleanly. (Not a > > major point, you can delete the directory manually after uninstalling, > but > > it's untidy). Maybe the uninstaller should just unconditionally delete > all > > of site-packages as well as whatever files it knows were installed. This > is > > a "normal" issue when installing into the system Python, but for people > who > > avoid that and use virtualenvs (e.g. me :-)) it's new (and annoying, as > > we'll never use the system pip in any case...) > > Can you not just teach the Python installer to check for pip and > remove it if found? > I'm not sure. That's my point, essentially. Who knows enough about the Windows installer to do this correctly? If the answer is "nobody", then is a best-efforts approach with some issues that we don't have anyone who knows how to solve, an acceptable approach? Maybe it is, I'm not claiming that this is a major issue, but we should note it in the PEP as a limitation. > This raises another point - to an extent, I don't care about any of this, > as > > I routinely use virtualenvs. But if using pip to manage the system > python is > > becoming the recommended approach, I'd like to understand what precisely > the > > recommendation is so that I can see if it's better than what I currently > do > > - for instance, I've never used --user so I don't know if it will be of > > benefit to me. I assume that this will go in the packaging user guide in > due > > course, but I don't know who will write it (does anyone have the relevant > > experience? most people I know recommend virtualenv...) > > If I could install everything I wanted with pip then virtualenvs would > be more practical. Maybe when wheel distribution becomes commonplace > I'll start doing that. I basically always want to install a large > number of third party packages before I do anything though. > > So for me the procedure on ubuntu is something like: > 1) install ubuntu > 2) sudo apt-get install python-numpy python-scipy python-matplotlib > ipython python-sympy python-dev cython python-pygraph python-tables > python-wxgtk2.8 python-pywt python-sphinx ... > > On Windows the procedure is: > 1) Install Python > 2) Get MSIs for numpy, scipy, wxPython, matplotlib, PyQt, numexpr, ... > 3) Setup PATH or create a shell/batch script called 'python' that does > the right thing. > 4) Run ez_setup.py and Install pip > 5) Patch distutils (http://bugs.python.org/issue12641) > 6) Use pip for cython, sympy, ipython, pyreadline, spyder, sphinx, > docutils, line_profiler, coverage, ... > 7) Build and install my own commonly used private packages. > 8) Get more prebuilt binaries for other awkward packages when > necessary: pytables, numexpr, mayavi, ... > > (You can see why some people just install Python(x, y) or EPD right?) > > It takes quite a while to do all this and then I have basically all > the packages I want minus a few pippable ones. At this point I don't > really see the point in creating a virtualenv except to test something > that I'm personally developing. Or am I missing something? > :-) Yes, it's a pain. My experience is better because I don't use that many packages that need binaries. For those that I do, I maintain a local cache of wheels that I convert from bdist_wininst installers using "wheel convert" and then pip install works for everything. This is a really slick experience, but it relies on me maintaining my local repo, and having an appropriate -i flag added to pip (or I put it in pip.ini). As I work on multiple PCs, it's still fiddly (I put the cache on my skydrive for ease). But yes, if I made extensive use of binary extensions, I'd hate this approach. That's why I keep saying that the biggest win for wheels will be when they become the common means of distributing Windows binaries on PyPI, in place of wininst/msi. Paul
_______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
