[tahoe-dev] [tahoe-lafs] #1200: package up Brian's New Visualization of immutable download

[tahoe-lafs]

#1200: package up Brian's New Visualization of immutable download
-----------------------------+----------------------------------------------
     Reporter:  zooko        |       Owner:  nobody                                                                    
         Type:  enhancement  |      Status:  new                                                                       
     Priority:  major        |   Milestone:  1.9.0                                                                     
    Component:  unknown      |     Version:  1.8β                                                                      
   Resolution:               |    Keywords:  unfinished-business immutable download statistics performance transparency
Launchpad Bug:               |  
-----------------------------+----------------------------------------------

Comment (by gdt):

 I'd like to suggest stepping back from the "python is special" view and
 consider how the rest of the open source world deals with dependencies.
 That said, I realize there is a desire to be able to download a tahoe
 tarball, unpack it, type something, and end up running.  I believe that
 for any popular program almost everyone runs it from a packaging system.
 So for development and evangelizing, easy build from source tarball is
 important, but for eventual widespread success, packaging systems are
 crucial.

 Right now we seem to have "build" and "install" steps, but build isn't
 really build - it's fetch/build dependencies.   And install runs the
 python compiler in addition to copying to DESTDIR.  From a packaging
 system viewpoint, automatic dependency fetching is a problem to be
 disabled.  So I'd like to suggest a new 'dependencies' setup.py target
 that obtains all missing dependencies, that build compile .py but not
 fetch dependencies or install, and that install just copy to DESTDIR.

 One obstacle to this approach is that some programs are written in
 languages that appear to have a tradition that people manually deal with
 files.  It's obvious to me :-) that javascript libraries should come in a
 tarball with a configure script, be given a --prefix, and get installed
 into $PREFIX/share/javascript/foo/bar.js, from which other programs that
 need them can obtain them.  Probably the build step (typing make) in the
 js package would run some program to convert from source to minified form,
 and make install would then install both.  Then a "binary package" of the
 javascript program can be distributed, and be a dependency in packaging
 systems.  (I find it odd that the javascript community hasn't done this,
 but java seems similar in the expectation that individuals who want to use
 programs get jar files and type 'java foo.jar' to run them.)   So one step
 would be to package up the javascript code first.

 The other obstacle is complexity.  As tahoe depends on something new, code
 to download and build those new things (presumably for use within the
 source tree, rather than installed) needs to be written. For a few
 javascript files, that might be simple enough to not be an issue.

 Essentially I'm arguing that a "./setup.py dependencies" step is a
 (reasonable and helpful) accomodation for people wanting to use tahoe
 without the dependencies already installed, and that the eventual large-
 scale approach would be to have dependencies already.

 Another option is to adopt the packaging-system-centric notions where it's
 reasonably easy (GNU/Linux, pkgsrc, etc.) and to provide a tarball of
 tahoe-dependencies that has things like the js libs.   Those tarballs
 could then be built for releases, but not stored in the version-control
 system.

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