[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 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? (My
 instinct: no. The distribute project changed a bunch of things without
 first writing unit tests, thus resulting in an even buggier codebase than
 the original setuptools. Then they abandoned (?) it.)

 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.

 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.

 Also, even to get that far would be a great deal of effort on our part,
 wouldn't it? Unless Distutils2, or pip, or something is a lot more
 functional than I thought.

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