installation todos since vendoring pkg_resources...

[qwcode]

3 todos related to installation since the vendoring of pkg_resources:

1. rebuild get-pip.py with the latest pip; specifically remove the setuptools/pkg_resources import check (https://github.com/pypa/pip/blob/develop/contrib/build-installer#L13)
2. we have to release a wheel of pip, for get-pip.py to work without setuptools
3. update the install instructions.

I have #3 done locally, and tested a locally updated get-pip.py using this

python get-pip.py --find-links=/local/pip/wheel/location --no-index

#1 should wait till we have as many fixes as possible.

do we have any concerns about #2?

[dstufft]

The biggest concern is that pip 1.4 didn't have proper script handling for Wheels so if you upgrade from 1.4 to 1.5+ with pip wheels you won't have a pip script. Not sure how much we care because in 1.4 Wheels were opt in an experimental.

[dstufft]

Just a thought, if we setup the dependency information correctly, then pip can depend on setuptools in the metadata, which would cause it to install setuptools itself even from a Wheel making get-pip.py give you pip + setuptools in one command.

[qwcode]

or have pip.bootstrap() include running pip install setuptools.

[dstufft]

Yea that would work too.

[qwcode]

but I'm imagining the people who'll relish the setuptools-free experience for whatever reason, and we're not allowing that. maybe a --no-setuptools option for get-pip.py.

[dstufft]

I'd be ok with that, though I don't know if it's needed. Worst case those people can always uninstall setuptools.

[qwcode]

so, ok, let's add that call, and make the install instructions even easier.

[qwcode]

although, I'm concerned pip install setuptools won't recognize existing distribute installs using the vendored pkg_resources. need to confirm what will happen in that case. that could be a reason to leave this call out.

could check for a distribute install, and don't run the setuptools install in that case.

[qwcode]

I confirmed pip-1.5.1 would force an uninstall of an existing distribute by running pip install setuptools. It's due to the lack of the distribute==setuptools hack (in distribute's pkg_resources, since we using our vendored one), plus the hacks we added for upgrading from distribute to setuptools.

we certainly don't want get-pip.py doing that upgrade automatically. it should check for an existing distribute, and not install setuptools.

[dstufft]

Hrm, is that really a bad thing though? Seems like we'd want to get people onto setuptools. Either way though we could just make the bootstrap install setuptools if setuptools isn't importable.

[qwcode]

I'm thinking of the people using distribute from the OS pkg mgr for whatever reason, and we go uninstall it.
It's pros and cons I guess.

if we did a check I was imagining using pkg_resources.get_distribution('distribute') to determine whether to install or not. In the case that they already have the setuptools distribution, pip install setuptools won't do anything.