[tahoe-lafs-trac-stream] [tahoe-lafs] #1326: don't require newer foolscap if you have older Twisted

[tahoe-lafs]

#1326: don't require newer foolscap if you have older Twisted
---------------------------+------------------------------------------------
     Reporter:  zooko      |       Owner:  somebody                                         
         Type:  defect     |      Status:  new                                              
     Priority:  major      |   Milestone:  1.8.2                                            
    Component:  packaging  |     Version:  1.8.1                                            
   Resolution:             |    Keywords:  review-needed setuptools install foolscap twisted
Launchpad Bug:             |  
---------------------------+------------------------------------------------

Comment (by zooko):

 Replying to [comment:2 davidsarah]:
 > Replying to [ticket:1326 zooko]:
 > > David-Sarah [http://tahoe-lafs.org/pipermail/tahoe-
 dev/2011-January/005867.html proposed] a different approach, in which
 {{{python setup.py build}}} would build a local private copy of
 {{{foolscap >= 0.6.0}}} even if the system already have
 {{{foolscap-0.5.1}}} installed.
 >
 > There must be some confusion -- this is what trunk ''already'' does.

 Hm, yes I didn't understand your proposal. On that mailing list message,
 you wrote:
  'setup.py build', by default, should either:
   - have built a private copy of twisted < 10.2 (always used by bin/tahoe)
    that won't be affected by upgrades of the installed version, or
   - have built a private copy of foolscap 0.6.0 (always used by
 bin/tahoe).

 So if I understand correctly, you prefer for Tahoe-LAFS v1.8.2 to require
 {{{foolscap >= 0.6.0}}} even if {{{Twisted}}} is {{{< 10.2}}} (or
 alternately to require {{{Twisted <= 10.2}}}) for installation, because if
 Tahoe-LAFS v1.8.2 allows {{{foolscap-0.5.1}}} at install time, then the
 user may later upgrade their {{{Twisted}}} to {{{>= 10.2}}} and then
 execute {{{bin/tahoe}}} without re-running {{{python setup.py build}}} and
 they would then get a failure to start due to conflicting version
 requirements.

 This is what trunk currently does.

 The drawback to this approach is [http://tahoe-lafs.org/pipermail/tahoe-
 dev/2011-January/005842.html Brian's original complaint] -- that it means
 Tahoe-LAFS requires {{{foolscap >= 0.6.0}}} when the {{{foolscap-0.5.1}}}
 that comes with Ubuntu Lucid should really be good enough.

 Now, I don't feel so strongly about this, so I'm basically {{{-0}}} on
 leaving trunk as it is, because I can live with it, but I would like to
 understand your motivation better in order to work with you on related
 issues.

 My idea of packaging is that there is a "build/install" step where the
 packaging system can do stuff having to do with dependencies--either
 automatically resolve dependencies (complicated and controversial, but
 handy for users who don't know how to resolve dependencies themselves), or
 at least detect unresolved dependencies and clearly alert the user to the
 problem and exit loudly. Then, at ''run-time'' the packaging system
 ''could'' re-examine dependencies in order to give a better error message
 if a dependency is missing or is of an incompatible version, but it ''must
 not'' resolve dependencies at that time.

 So I have the feeling that if the user changes installed deps after build
 time and before run-time, then we have no responsibility beyond erroring
 out cleanly, but you seem to think we should pay a cost (in the form of a
 higher version requirement on {{{foolscap}}}) in order to make Tahoe-LAFS
 run correctly even if the user has done that,.

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