introducer welcome page broken with current Foolscap

[warner]

The foolscap-0.9.1 release made a change to the internals of how connection hints are represented. Unfortunately Tahoe 1.10.2 depended upon this internal representation (3-tuples of ("tcp", host, port)), and when faced with the 0.9.1 version (strings of host:port or tcp:host:port), it throws an exception when trying to render the introducer's Welcome page.

I might have fixed this in tahoe trunk, in which case the resolution will be to spin a new tahoe-1.10.3. I *think* I fixed it to tolerate both old and new-style representations, so we don't strictly need to increase the foolscap dependency, but other 1.10.3 features may make that a good idea.

[warner]

BTW the traceback ends with:

/home/warner/stuff/tahoe/mf-test/tahoe-lafs/src/allmydata/util/rrefutil.py, line 36 in hosts_for_rref
34    # Foolscap-0.2.5 and earlier used strings in .locationHints, but we
35    # require a newer version that uses tuples of ("ipv4", host, port)
36->  assert not isinstance(hint, str), hint
37    if hint[0] == "ipv4":

[warner]

Yeah, I fixed this in tahoe trunk a few weeks ago (22-sep-2015, commit 1ffc653). So what this really needs is a tahoe-1.10.3 .

[daira]

I think foolscap should change to be compatible with old Tahoe-LAFS. It's important for old Tahoe used with new foolscap not to break.

[zooko]

It's important for old Tahoe used with new foolscap not to break.

I'm not sure I agree. Few users are going to upgrade their foolscap while keeping their old Tahoe?

[daira]

Replying to zooko:

It's important for old Tahoe used with new foolscap not to break.

I'm not sure I agree. Few users are going to upgrade their foolscap while keeping their old Tahoe?

I do it all the time. (Not explicitly upgrading, but rebuilding an existing source checkout of Tahoe, which picks up the latest foolscap.)

[zooko]

Rebuilding will re-use the locally present install of foolscap (in ./support or in the local operating system's default Python directories), so this would happen only if the user deleted their current foolscap and then rebuilt. In any case, I don't think Brian wants to make foolscap backwards compatible in this way so I propose that we close this ticket as fixed.

[zooko]

Assigning to daira to either close as fixed or to persuade Brian to do something different.

[warner]

I'd really rather not re-introduce the old representation into Foolscap: it is cleaner without doing that kind of parsing (foolscap no longer parses the location hint strings itself: the connection plugins now own that responsibility).

To make older tahoes behave correctly with the latest foolscap, I'd need to add a hint-parser that was used for nothing but backwards compatibility, which would probably give weird results when used with new features like onion endpoints. And introduce a new attribute (.locationHints2?) that would look kinda ugly.

This will generally be resolved by the tahoe-1.10.3 release, at which point the current version of Tahoe will work with all versions of Foolscap (at least w.r.t. this issue). Are you comfortable allowing that to be the resolution of this ticket? And/or WONTFIXing this one?

[daira]

This is fixed from Tahoe's point of view. We also intend to bump Tahoe's dependency on foolscap, even though that isn't strictly necessary for this ticket.

[warner]

Milestone renamed