mini-Summit report, day 2

[Jimmy Tang]

Hi All,

I may be late jumping into this discussion, but I've been working on a
cross-platform build system which might help address some of these
packaging and dependency issues. See https://github.com/hashdist/hashdist.
The idea is to provide a build/environment which can be repeatably built
and rebuilt, it takes the input parameters and then hashes it to a
destination for the output.

I would imagine it would not take very much effort to build a 'stack' for
tahoe-lafs. The user would just need to have python, git and a c compiler
to build the tahoe-lafs application.

disclaimer: I'm using hashdist for a few work related things as well as
personal projects and I'm actively submitting PR's to the hashstack repo.


Jimmy


On Thu, Jul 17, 2014 at 12:56 PM, Greg Troxel <gdt at ir.bbn.com> wrote:

>
> Brian Warner <warner at lothar.com> writes:
>
> > On 7/2/14 2:50 PM, Greg Troxel wrote:
> >
> >> Hopefully this has a way to avoid doing any fetching of dependencies,
> >> and failing instead, and is no less cross unfriendly than python has
> >> to be to start with. (From packaging system view) tahoe really doesn't
> >> seem all that special - it's just a bunch of python code with a list
> >> of dependencies, so it seems symptomatic of larger brokenness in the
> >> python world that this is necessary...
> >
> > Indeed :). Python's current package-installation tools don't make it
> > easy to categorically prevent all fetching, but I think we can work
> > around that.
> >
> > The "safe" thing to do involves a setup phase:
> >
> > 1: identify the transitive closure of modules needed to run tahoe, by
> >    doing an unsafe "pip install tahoe" and seeing what it fetches.
> > 2: set aside the tarballs used during that recursive install
> > 3: inspect that code, somehow, and record the hashes of the tarballs
> > 4: be prepared to repeat this process each time we want to update
> >    anything
>
> I think this is overkill, and dragging in things that belong in a
> packaging system.   Dependencies should just be expressed and required
> to be there already.   I see where this is coming from, but it seems
> crazy for every project to have to deal with this.
>
> I don't care if this happens, but I think the production build should
> (at least optionally) follow packaging norms, which is to document
> dependencies in a README and just error out if they are not present.
>
> > None of this is specific to Tahoe, but Tahoe is among the few projects
> > with users who care deeply about not just installing random code found
> > on the internet :).
>
> True.  There are two reasons to avoid downloading as part of build.  One
> is security, and the other is repeatability and packaging system
> containment.  Maybe all python programs are this bad, and I've only
> noticed it in tahoe because that's the one I've been involved in
> packaging.
>
> _______________________________________________
> tahoe-dev mailing list
> tahoe-dev at tahoe-lafs.org
> https://tahoe-lafs.org/cgi-bin/mailman/listinfo/tahoe-dev
>
>


-- 
http://www.sgenomics.org/~jtang/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://tahoe-lafs.org/pipermail/tahoe-dev/attachments/20140719/f6fc433d/attachment.html>