[tahoe-lafs-trac-stream] [tahoe-lafs] #1451: yet another failure of setuptools to set up a correct sys.path

[tahoe-lafs]

#1451: yet another failure of setuptools to set up a correct sys.path
----------------------------+------------------------
     Reporter:  davidsarah  |      Owner:  somebody
         Type:  defect      |     Status:  new
     Priority:  major       |  Milestone:  undecided
    Component:  packaging   |    Version:  1.8.2
   Resolution:              |   Keywords:  setuptools
Launchpad Bug:              |
----------------------------+------------------------

Comment (by davidsarah):

 Replying to [comment:3 zooko]:
 > Replying to [comment:1 davidsarah]:
 > > This is getting ridiculous -- we've had dozens of instances where
 setuptools sets up a sys.path that loads the wrong code, all for subtly
 different reasons. IMHO, setuptools has to go.
 >
 > Maybe we should open a ticket named "setuptools delenda est", or instead
 start a mailing list thread. My first question would be: is there reason
 to believe it would be worth switching to {{{distribute}}} instead?

 No. {{{distribute}}} doesn't seem to have fixed any of the things in
 setuptools that I consider most broken, and has introduced its own bugs.

 > What about the new Distutils2 project? (The successor from the same
 group that did the aforementioned "distribute" project.) As far as I know
 it isn't yet supported by the makers of our deps, so for example as far as
 I understand the pyOpenSSL project doesn't -- or can't? -- produce a
 package which provides pyOpenSSL on Windows when the user doesn't have a
 compiler.

 If setuptools is used to produce a given pyOpenSSL egg, that doesn't mean
 you need setuptools to run an application that uses it. That's just a
 matter of putting the egg in the ''right'' position on the {{{sys.path}}}
 (which setuptools can't do reliably), and then the Python !ZipImport
 machinery will load it, including loading native libraries.

 So run-time should be easy, and we shouldn't need the script that
 setuptools generates in the support directory.

 At build-time, we do need to run the {{{setup.py}}} files of dependencies.
 If we build them in subprocesses, set up the {{{sys.path}}} for each
 subprocess correctly (i.e. with that package's build-time dependencies),
 and prevent setuptools from downloading packages, then the scope that
 setuptools has to mess up each build is much reduced. Then we can
 incrementally change (or persuade its maintainers to change) each package
 to not depend on setuptools at build time.

 > Now we could still make our build system build Tahoe-LAFS on all
 supported operating systems including Windows when the user does have a
 compiler, and we could still provide a complete pre-built bundle of
 binaries of pyOpenSSL with Tahoe-LAFS for certain specific operating
 systems, but this would mean users no longer have the ability to acquire
 binaries of deps from upstream (e.g. pyOpenSSL maintainers) and source
 code from Tahoe-LAFS and use the two together.

 No, because ''if'' the pyOpenSSL maintainers want to continue to use
 setuptools to generate their eggs, we're not stopping them. It's our own
 use of setuptools that we want to replace, because that's where most of
 the problems lie.

-- 
Ticket URL: <http://tahoe-lafs.org/trac/tahoe-lafs/ticket/1451#comment:4>
tahoe-lafs <http://tahoe-lafs.org>
secure decentralized storage