Autosetuptools

[dholth]

The autosetuptools branch fixes wheel installs compared to the previous PR.

This is a rough PR for discussion.

This version of pip uses its own copy of pkg_resources and installs setuptools when it needs it. It doesn't necessarily remove enough options from install command so the re-run only fetches setuptools (maybe add a special "only setuptools" flag) and it probably fetches the first package that needed setuptools twice.

If the install needs setuptools, NeedSetuptools() is raised. The runner catches it, runs the command with the same options, then retries with the original arguments to the install command.

We can't just add setuptools to the requirements in the same install loop because everything is installed at once or not installed at all; packages in the build/ directory are not added to sys.path when we're getting the egg-info. However when you're running setuptools' own setup.py then setuptools is available on sys.path by virtue of being the cwd.

Even without all the automatic rigamorole, being able to install setuptools without having a (working) version is nice. Just expect to need to run "python -m pip ..." if the wrapper script is trying to import a missing pkg_resources.

I think some of the bdist_wheel "needs setuptools to --use-wheel" checks (no longer the case after this patch) were mixed up with the "needs setuptools to build wheels" check that will be necessary.

I tried the distlib pkg_resources emulation but my virtualenvs tend to use enough pkg_resources features that I need the setuptools version.

[qwcode]

can we just have one pull?

[qwcode]

ok, I see, you started off in your develop branch, in the original one.

[qwcode]

I think each pip version should set a setuptools requirement (based on our testing), not just "setuptools"
If setuptools is installed and doesn't meet the requirement, I think we should prompt them for what they want to do. "Proceed at risk, or Allow pip to re-install". they could set the permanent answer in their config or environment.

[dholth]

That's a good idea and would help me; I'm always getting older versions of setuptools by accident.

Except -1 on the interactive prompt.

[qwcode]

In the case where we'd be upgrading, not sure we can just presume. they're just trying to install some package, and we go upgrade setuptools.

[dholth]

I think I prefer to exit with an error code and something like a "please upgrade setuptools or use --force" message if setuptools is installed but too old. We'll get there when we get there.

[dholth]

@qwcode said:

"any wheel for a setuptools-based setup.py that uses the "scripts" keyword or console entry points will need pkg_resources. most won't naturally add a dependency on setuptools for that. so, that is our problem, right?"

The next pip should generate the console_scripts style scripts at install time and will be able to determine whether that merits a pkg_resources dependency. We would be able to have more than one console_scripts implementation depending on the user's preference: compatible, fast, or nothing.

The distutils scripts= keyword is different and just copies the script. You can put non-Python scripts in there too. [TODO check if touches the .py extension]

[dholth]

Woot!

[qwcode]

The first step here is for everyone to come to consensus on what solution to pick from #1049
Although this scenario ranks well based on the pros and cons IMO, this is one of multiple scenarios.

[qwcode]

closing, vendoring will happen in another PR that is specifically about vendoring, and not the auto-install