[tahoe-dev] help! how do I manage dependencies on JavaScript code?

[Zooko O'Whielacronx]

On Fri, Sep 3, 2010 at 6:41 AM, Randy Bush <randy at psg.com> wrote:
> tahoe-lafs already requires far more than i would like to see.  adding
> more, and a java engine on top, is just way too much.  please refrain
> from the disease.

Not Java. No way! :-) JavaScript. Totally different. Also it will be
optional and should not get in your way at all if you don't want it.
Brian had previously suggested to me something along the lines of what
Greg Troxel just posted: have Tahoe-LAFS emit download stats in a
machine-readable form and have the visualization be basically a
completely separate (but integrated) app.


We still have, as you correctly note, plenty of headaches with our
current dependencies. The current two biggest offenders in my opinion
are PyCrypto and pycryptopp.

I would love to stop depending on PyCrypto entirely. We are not even
benefiting from it! I don't trust it to be secure, and we are going to
add a note warning the user not to rely on it (#1192). So it is giving
us no benefits and only packaging headaches.

Here is a ticket aimed at making it so that we do not bring PyCrypto in at all:

http://twistedmatrix.com/trac/ticket/4633# allow applications to
"bring their own crypto" to avoid the dependency of conch on PyCrypto

Now pycryptopp's problems mostly have to do with C++ compilation and
linking. I'm the maintainer of pycryptopp and I've actually been
spending a bit of time in the last week working on those. The current
trunk (not yet released) version of pycryptopp builds and passes tests
on FreeBSD, as you can see here thanks to Randy's buildslave:

http://tahoe-lafs.org/buildbot-pycryptopp/waterfall

I intend to put out a release of pycryptopp real soon now that will
satisfy Tahoe-LAFS's dependency on pycryptopp and install easily on
all our supported platforms.

Regards,

Zooko

http://tahoe-lafs.org/trac/tahoe-lafs/ticket/1192# warn users not to
rely on PyCrypto