investigate newer setuptools #2044

New Issue

tahoe-lafs · 2013-08-05T23:51:56Z

daira commented

2013-08-05 23:51:56 +00:00

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.

What is [setuptools 0.7+](https://bitbucket.org/pypa/setuptools/overview) ? 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.

tahoe-lafs added the

labels 2013-08-05 23:51:56 +00:00

tahoe-lafs added this to the undecided milestone 2013-08-05 23:51:56 +00:00

daira commented

2013-08-27 11:55:43 +00:00

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

tahoe-lafs added

major

and removed

normal

labels 2013-08-27 11:55:43 +00:00

tahoe-lafs modified the milestone from undecided to soon

2013-08-27 11:55:43 +00:00

zooko commented

2013-09-12 13:19:40 +00:00

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:

changeset: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]changeset:c045241a5505684831f7c0fed74f94e8ec0a7e8e/trunk#file20 (#1074)
changeset: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"
changeset: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".
changeset: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 .
changeset:84cd0d991a1b121ab2d27d8cc09b37ba52ec2841 This was fixed in upstream distribute: https://bitbucket.org/tarek/distribute/issue/147/respect-the-sysdont_write_bytecode-flag .
changeset:0e20ab6003dec602b3adb53b6ec029cd535bec98 "Tolerate import errors when loading extra commands for "setup.py --help-commands""
changeset: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.

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: * changeset: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]changeset:c045241a5505684831f7c0fed74f94e8ec0a7e8e/trunk#file20 (#1074) * changeset: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" * changeset: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](http://bugs.python.org/setuptools/issue17)), thus allowing us to do away with the "--site-dirs=" kludges, which are currently breaking some of our buildbots." I believe that [setuptools #17](http://bugs.python.org/setuptools/issue17) 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". * changeset: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> . * changeset:84cd0d991a1b121ab2d27d8cc09b37ba52ec2841 This was fixed in upstream distribute: <https://bitbucket.org/tarek/distribute/issue/147/respect-the-sysdont_write_bytecode-flag> . * changeset:0e20ab6003dec602b3adb53b6ec029cd535bec98 "Tolerate import errors when loading extra commands for "setup.py --help-commands"" * changeset: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 commented

2013-09-12 13:22:17 +00:00

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.

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 commented

2014-04-14 21:37:15 +00:00

This might help with #2217.

This *might* help with #2217.

zooko commented

2015-02-25 14:06:33 +00:00

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

tahoe-lafs modified the milestone from soon to 1.11.0

2015-05-04 23:29:46 +00:00

tahoe-lafs changed title from ~~investigate setuptools 0.7+~~ to investigate newer setuptools

2015-07-21 20:01:57 +00:00

warner commented

2016-03-22 05:02:52 +00:00

Milestone renamed

warner modified the milestone from 1.11.0 to 1.12.0

2016-03-22 05:02:52 +00:00

warner commented

2016-03-26 22:46:06 +00:00

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.

warner added the

fixed

label 2016-03-26 22:46:06 +00:00

warner modified the milestone from 1.12.0 to 1.11.0

2016-03-26 22:46:06 +00:00

warner closed this issue

2016-03-26 22:46:06 +00:00

Sign in to join this conversation.