[tahoe-dev] 0.8.2b1 - new/wrong dependencies

[Greg Troxel]

David-Sarah Hopwood <david-sarah at jacaranda.org> writes:

> On 2011-01-29 02:04, Greg Troxel wrote:
>> 
>> I attempted to update the pkgsrc package to 0.8.1b1.
>> 
>> I found that it tried to download something called "mock" that I had
>> never heard of, and had not seen announced as a new prereq.
>
> New prerequisites are announced in the NEWS file:
>
>  - Tahoe now depends upon the "mock" testing library, and the foolscap
>    dependency was raised to 0.6.1 . It no longer requires pywin32 (which
>    was used only on windows). Future developers should note that
>    reactor.spawnProcess and derivatives may no longer be used inside
>    Tahoe code.
>
> Note that mock was previously required to run the test suite; the change
> is that it is now required unconditionally.

Perhaps I'm the only one with this notion, but I think changes to
prereqs should be announced in email to the dev list.  I've been reading
the list reasonably carefully since before this change.

It's great that this is in NEWS, but scanning NEWS to find the current
state isn't scalable.

>> This dependency should be listed in the detailed installation
>> instructions which should be included in the tarball.
>
> The canonical place to look for Tahoe's direct run-time dependencies is
> src/allmydata/_auto_deps.py . That *is* documented in the detailed

I did find this by reading the code, but having to do that crosses the
user/developer boundary.

> installation instructions, which are on the wiki at
> <http://tahoe-lafs.org/trac/tahoe-lafs/wiki/AdvancedInstall>.

My point, perhaps not well made, was that this information belongs in
the tarball, as the wiki is not accessible for offline use.  (I use
computers not connected to the internet, for various reasons, more than
most people.)

> (The link to _auto_deps.py there was broken, I've just fixed it.)
>
> This does not include indirect dependencies, which are currently
> zbase32, pyutil and argparse. Unfortunately the method of finding
> indirect dependencies documented in AdvancedInstall only gives you
> the versions of those that are being used by a given build of Tahoe;
> I've filed <http://tahoe-lafs.org/trac/tahoe-lafs/ticket/1343> for
> that.

I think that the installation instructions should simply have a list of
programs, versions, and upstream websites.   Most GNUish programs have
this in README at top level, and pretty much say "make sure these are
installed and then run ./configure normally".

I'm not sure what you mean by indirect dependency.  In pkgsrc tahoe-lafs
depends on zbase32, but perhaps I got that wrong.  To be an indirect
dependency in pkgsrc, e.g., nothing in the tahoe-lafs code can refer to
zbase32.  But in my pkgsrc install (again, quite probably I packaged
things wrong), nothing else depends on zbase32.

> I'm agnostic about whether the detailed installation instructions
> should be on the wiki or in the source tree, as long as they are not
> duplicated in both places.

I feel pretty strongly that they belong with the code for two reasons
 a) the wiki is not distributed in the tarball and thus inaccessible to
 those without an internet connection that minute
 b) documentation should be versioned with the code

> It's a bug that this automatic download can't be switched off:
> <http://tahoe-lafs.org/trac/tahoe-lafs/ticket/1220> (and thanks for
> reporting that bug). My position on that is still what I said in
> comment:19 of that ticket:
>
>   ... I favour making sure that a replacement for setuptools -- probably
>   Brian's "unsuck" branch -- follows [open source packaging] norms by
>   default, rather than continuing to hack at zetuptoolz. zooko's efforts
>   with the latter are appreciated, but that approach has consumed an
>   enormous amount of development effort, and is still causing obscure and
>   often irreproducible bugs on our buildslaves and for our users.
>
> Replacing our use of setuptools/zetuptoolz probably won't happen before
> Tahoe v1.10, though.

Thanks; I understand this is hard to fix.

>> But, I have compatible twisted and foolscap installed, which should be
>> ok (and of course packaging systems don't allow build-time downloads):
>> 
>> py26-foolscap-0.5.1 Foolscap contains an RPC protocol for Twisted
>> py26-twisted-10.1.0 Framework for writing networked applications
>
> This issue was discussed at length by the core developers, but
> unfortunately it was not feasible to require an earlier version of
> foolscap when the installed Twisted version is before 10.2. See
> <http://tahoe-lafs.org/trac/tahoe-lafs/ticket/1326#comment:7> for the
> details.

Sorry, I was trying to pay attention and I think remembered the "this is
how it ought to be conclusion" rather than the "it's too hard to do"
reality.

Thanks for listening and responding; I know I'm sounding difficult, but
packaging issues are critical because when tahoe has 1E7 users all but a
handful will be using packaged versions from their OS packaging system.
(I realize packaging issues are secondary to the development crowd who's
always running out of darcs/git.)

I have already packaged mock (python distutils packages are trivial to
package) and will finish updating foolscap, and then all should be well.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 194 bytes
Desc: not available
URL: <http://tahoe-lafs.org/pipermail/tahoe-dev/attachments/20110129/8c472738/attachment.pgp>