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