make "tahoe create-client --hide-ip" fail if txtorcon/txi2p are not installed

[warner]

This would speed up the interactive discovery process when a node admin tries to set up a tor/i2p -based node. Instead of:

• pip install tahoe-lafs
• tahoe create-client --hide-ip
• edit tahoe.cfg
• tahoe start
• error: txtorcon not installed
• pip install tahoe-lafs[tor]
• tahoe start
• no error, but welcome page shows connection not established
• oops, apt-get install tor
• tahoe restart
• ok

we could make it:

• pip install tahoe-lafs
• tahoe create-client --hide-ip
• error: txtorcon not installed
• pip install tahoe-lafs[tor]
• tahoe create-client --hide-ip
• edit tahoe.cfg
• tahoe start
• no error, but welcome page shows connection not established
• oops, apt-get install tor
• tahoe restart
• ok

And then maybe we can detect that there's no tor daemon available too (perhaps create-client could try to establish a connection to a tor server we run on tahoe-lafs.org, or torproject.org, or something), and cut down a few more steps.

I think #2820 and having create-client disable the tub listeners would remove the need for the edit tahoe.cfg step.

[warner]

This should go into Node.init_connections, at the end, where if not self._reveal_ip, we check to see that at least one of handlers["tor"] or handlers["i2p"] is not None. If not, throw an error.

[dawuud]

fixed here ​https://github.com/tahoe-lafs/tahoe-lafs/pull/353

[warner]

Oh, I tried to write some tests for your branch, and I discovered that I was wrong about this needing to go into init_connections(). The #2820 change makes create-client --hide-ip set tcp = tor, which then triggers an error at startup (unavailable/unimportable handler type 'tor'. Please pip install tahoe-lafs[tor] to fix.), so we don't need a new error in init_connections(). (in the test I added, it kept bailing before the new error that you added)

Instead, I think we need new code in tahoe create-client, to make --hide-ip try to import the Foolscap/Tor connection handler, and give that same useful error message if it fails. This should probably be done as part of the #2490 "create-node-does-tor" changes.

[meejah]

How's this? ​https://github.com/tahoe-lafs/tahoe-lafs/pull/372

[warner]

Fixed in [783449b].

[warner]

One leftover note: it'd be nice if the outbound-connection-hint-handler side of tahoe only relied upon foolscap[tor] (or i2p), and didn't look for txtorcon/txi2p directly. So, at least in theory, Foolscap could change the way it accesses Tor, to use something other than txtorcon, and tahoe's outbound side should still work. Of course there's not really much point in doing that, since the inbound side (tor_provider) really does need txtorcon. Same for I2P.

So I don't really want to change anything, but just so I remember the idea for the future, ideally it'd be nice if create_node either tried to import foolscap.connections.tor (and caught the failure) to detect when tor was unavailable, or delegated the question to some tor_provider method. Maybe TorProvider.is_available()?