On Jul 13, 2013, at 9:59 AM, Brett Cannon wrote: > > > > On Sat, Jul 13, 2013 at 11:15 AM, Paul Moore <p.f.mo...@gmail.com> wrote: > On 13 July 2013 16:03, Donald Stufft <don...@stufft.io> wrote: > > > 1. Install to user-packages by default. > > Do people really want this? I hadn't seen it (other than if pip was installed > to user by default). I think it's a bad idea to switch this on people. I > doubt the user-packages is going to be in people's default PATH so they'll > easily get into cases where things are installed but they don't know where it > was installed too. > > I believe Nick wants to make user-packages the default. I know at least some > of the pip maintainers (yourself included) have reservations. Personally, > I've never used user-packages, so I don't know what issues might arise. But I > hope to try it out sometime when I get the chance, just to get some specific > information. > > I would assume the executable script was installed next to the python binary > but the library parts went into user-packages. That way -m would work for all > binaries of the same version. > > > > 2. Not depend on setuptools (??? - Nick's "inversion" idea) > > I wanted to do this anyways. It will still "depend" on it, but it will just > bundle setuptools itself like its other dependencies. For pip dependencies > are an implementation detail not an actual thing it can/should have. > > Bundling is not the same as Nick's suggestion. I personally have no problem > with bundling, but pip install with a bundled setuptools might not work > because the setup subprocess won't see the bundled setuptools when it imports > it in setup.py. But either way, it's doable, I just want to know if it's on > the critical path... > > > 3. Possibly change the wrapper command name from pip to pip3 on Unix. > > Not sure on this. Ideally i'd want the commands to be pipX.Y, pipX, and pip > all available and not install the less specific ones if they already exist > but that might be too hard? > > Could we just start to move away from an executable script and start > promoting rather aggressively -m instead? It truly solves this problem and > since the results are tied to the Python executable used (i.e. where > something gets installed) it disambiguates what Python binary pip is going to > work with (something I have trouble with thanks to Python 2 and 3 both being > installed and each with their own pip installation). I realize older Python > versions can't do this (I believe 2.6 and older can't for packages) but at > least in the situation we are discussing here of bundling pip it's not an > issue.
No, this is not how any user ever will expect unix programs to work. I know that python -m is very cute, and I use it myself for some debug and helper functionality at times, but it can never replace normal scripts. This is a user experience expectation, and we will have to meet it. --Noah
signature.asc
Description: Message signed with OpenPGP using GPGMail
_______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
