mini-Summit report, day 2

Greg Troxel gdt at ir.bbn.com
Thu Jul 17 11:56:42 UTC 2014


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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 180 bytes
Desc: not available
URL: <http://tahoe-lafs.org/pipermail/tahoe-dev/attachments/20140717/9680385b/attachment.pgp>


More information about the tahoe-dev mailing list