investigate newer setuptools

[daira]

What is ​setuptools 0.7+ ?

Does setuptools 0.9.* fix any of the bugs we care about?

What happens when you try to use zetuptoolz on a system with setuptools 0.7+ installed?

These questions --and many others-- will be answered in the next episode of the ongoing saga that is Tahoe-LAFS packaging.

[daira]

Apparently setuptools 0.6 (which zetuptoolz is forked from) does not verify SSL :-(, and setuptools 0.7+ does.

[zooko]

I just read through our revision control history of the bundled copy of setuptools, and here are all the patches that I saw that we applied that aren't (or weren't) in upstream setuptools:

• c045241a5505684831f7c0fed74f94e8ec0a7e8e: two changes: 1. some changes to launcher on Windows (see #1074), and 2. if site.py was not generated by setuptools, treat this as just a warning, not an error: code (#1074)
• 4d785cfe3079a7f09f30621d4e4dba69460599ef: "this version completes my patch to fix ​​http://bugs.python.org/setuptools/issue54 , which is necessary for tahoe to build with --prefix=support without doing a lot of PYTHONPATH gymnastics around the call to setup.py"
• 5c0d937eececedbc98d16829f33a6765b7058f38: "Hopefully this one fixes the issue with easy_install not searching the sys.path for packages that were requested to be installed, (​setuptools #17), thus allowing us to do away with the "--site-dirs=" kludges, which are currently breaking some of our buildbots." I believe that ​setuptools #17 is fixed in newer setuptools's, although there was at one point a regression that broke it again in "distribute", so the very latest setuptools's might have inherited that regression if they are now taking code back from "distribute".
• 4d785cfe3079a7f09f30621d4e4dba69460599ef "this version completes my patch to fix ​​http://bugs.python.org/setuptools/issue54 , which is necessary for tahoe to build with --prefix=support without doing a lot of PYTHONPATH gymnastics around the call to setup.py"; This patch was never accepted into setuptools, at least not in setuptools v0.6, according to ​http://bugs.python.org/setuptools/issue54 .
• 84cd0d991a1b121ab2d27d8cc09b37ba52ec2841 This was fixed in upstream distribute: ​https://bitbucket.org/tarek/distribute/issue/147/respect-the-sysdont_write_bytecode-flag .
• 0e20ab6003dec602b3adb53b6ec029cd535bec98 "Tolerate import errors when loading extra commands for "setup.py --help-commands""
• 06a8b1ea84fd67c019ef91c28c18ddcc9ea2ecb8 "pkg_resources: better error message on bad spec"

That's all! There are only seven patches that we need to confirm whether they are fixed upstream, or port our patches to the new setuptools, or decide that we don't mind a regression by losing this patch.

Also dstufft mentioned that he would be willing to consider accepting these patches upstream if they aren't already there.

[zooko]

Dear geal:

Thank you for working on this! Please add the "review-needed" tag to this ticket once this ticket has a link to a github pull request or a patch that fixes it.

[daira]

This might help with #2217.

[zooko]

dstufft pointed out on IRC that the latest setuptools refuses to download dependencies from PyPI over insecure HTTP. This is an important feature.

[warner]

Milestone renamed

[warner]

We've removed zetuptoolz, and we now require a non-ancient version of setuptools. Also, our new virtualenv-based install instructions will generally give users a very modern setuptools, and current pip does the right thing with TLS. Time to close this one.