[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 zooko):

 gdt:

 Replying to [comment:9 gdt]:
 > So for development and evangelizing, easy build from source tarball is
 important, but for eventual widespread success, packaging systems are
 crucial.

 Okay, I agree that both running the code directly from upstream-tahoe-
 project -> user and running the code from upstream-tahoe-project ->
 packager -> user are important use cases.

 Now, let's get down to brass tacks here. What changes are you suggesting?

 > 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.

 This is #1220. If I understand correctly, the current state of that ticket
 is that {{{--single-version-externally-managed}}} satisfies the original
 requirements of the ticket, but that gdt then added a new requirement
 which is that the setup step should check for dependencies and stop with
 an error message if they aren't satisfied. ;-) Let's follow up on that
 ticket... Here: comment:21:ticket:1220

 >   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

 Okay I opened #1270 (have a separate build target to download any missing
 deps but not to compile or install them).

 > 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.

 That all sounds pretty good to me, but note that tahoe-lafs supports
 platforms that do not have "make" (i.e., Windows), so we can't rely on
 make.

 > 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.

 I guess that is the tahoe-deps notion:

 http://tahoe-lafs.org/source/tahoe-lafs/deps/tahoe-deps.tar.bz2

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