Changes between Initial Version and Version 1 of Ticket #1383


Ignore:
Timestamp:
2011-03-30T20:54:21Z (13 years ago)
Author:
davidsarah
Comment:

(Removed commentary about possible fixes from Description; the Description should only describe the bug.)

zooko wrote:

Could you help us make sure this is what happened by telling us about your installation of foolscap? I haven't heard of this problem before, so perhaps you did something that most people don't do, such as installing foolscap yourself before installing Tahoe-LAFS, and doing so without having setuptools installed.

Charles replied on tahoe-dev that he believed the installation was by apt-get, on fully-patched Ubuntu 11.04 alpha3.

A quick workaround for you would be to delete whatever installation of foolscap you have there and rerun Tahoe-LAFS's python setup.py build. This will cause it to download foolscap source code and build a new package.

I'm not sure what a better long-term solution would be. I can think of a few things that would make sure this problem doesn't happen again to someone else:

  1. The maintainer of foolscap (Brian Warner) could make setuptools a hard requirement to build foolscap packages so that people wouldn't get foolscap packages without the 'secure_connections' feature declared.
  1. We could hack the fork of setuptools which is bundled into the Tahoe-LAFS source tree (sometimes called "zetuptoolz") so that it doesn't treat a missing extra as a fatal error. The theory being that if the package doesn't declare an extra then probably it actually has that extra but didn't declare it.

Well, if the installed package doesn't satisfy the dependency (for whatever reason), then setuptools should try to download a version that does. Even if the latter has the same version number, it might not have the same packaging error.

OTOH I'm pretty hacked off with the quantity and subtlety of setuptools bugs and misdesign; we've reached a point of diminishing returns in attempting to fix it.

  1. The maintainer of foolscap could make pyOpenSSL a hard requirement of foolscap instead of an "extra". I think there used to be a user of foolscap who wanted to use it without secure connections, but perhaps they've stopped using it that way. In any case, it wouldn't harm them very much if it came with secure connections even if they didn't want to use them.

Hm... try as I might I can't think of any other solutions that I would support besides these three. One solution that I would not support is to add documentation to ​quickstart.html instructing the user to install pyOpenSSL manually, or to install setuptools manually before installing foolscap.

Oh, there is one more possibility:

  1. Add a declaration to Tahoe-LAFS that it depends on pyOpenSSL and remove from foolscap the declaration that it depends on pyOpenSSL. This is technically incorrect (Tahoe-LAFS doesn't depend on pyOpenSSL directly), but Tahoe-LAFS's build scripts are guaranteed to be executed with setuptools present, so we can at least make it work for all users that way.

Legend:

Unmodified
Added
Removed
Modified

  • Ticket #1383

    • Property Priority changed from minor to major

  • Ticket #1383 – Description

    initial v1  
    4747
    4848I guess you have an installation of foolscap which doesn't declare that it has an extra feature named {{{'secure_connections'}}}. Tahoe-LAFS specifies that it depends on foolscap ''with'' the {{{'secure_connections'}}} feature.
    49 
    50 Could you help us make sure this is what happened by telling us about your installation of foolscap? I haven't heard of this problem before, so perhaps you did something that most people don't do, such as installing foolscap yourself before installing Tahoe-LAFS, and doing so without having setuptools installed.
    51 
    52 A quick workaround for you would be to delete whatever installation of foolscap you have there and rerun Tahoe-LAFS's {{{python setup.py build}}}. This will cause it to download foolscap source code and build a new package.
    53 
    54 I'm not sure what a better long-term solution would be. I can think of a few things that would make sure this problem doesn't happen again to someone else:
    55 
    56 1. The maintainer of foolscap (Brian Warner) could make {{{setuptools}}} a hard requirement to build foolscap packages so that people wouldn't get foolscap packages without the {{{'secure_connections'}}} feature declared.
    57 
    58 2. We could hack the fork of setuptools which is bundled into the Tahoe-LAFS source tree (sometimes called "zetuptoolz") so that it doesn't treat a missing extra as a fatal error. The theory being that if the package doesn't declare an extra then probably it actually has that extra but didn't declare it.
    59 
    60 3. The maintainer of foolscap could make {{{pyOpenSSL}}} a hard requirement of foolscap instead of an "extra". I think there used to be a user of foolscap who wanted to use it without secure connections, but perhaps they've stopped using it that way. In any case, it wouldn't harm them very much if it came with secure connections even if they didn't want to use them.
    61 
    62 Hm... try as I might I can't think of any other solutions that I would support besides these three. One solution that I would ''not'' support is to add documentation to [http://tahoe-lafs.org/source/tahoe-lafs/trunk/docs/quickstart.html quickstart.html] instructing the user to install {{{pyOpenSSL}}} manually, or to install {{{setuptools}}} manually before installing foolscap.
    63 
    64 Oh, there is one more possibility:
    65 
    66 4. Add a declaration to Tahoe-LAFS that it depends on {{{pyOpenSSL}}} and remove from foolscap the declaration that it depends on {{{pyOpenSSL}}}. This is technically incorrect (Tahoe-LAFS doesn't depend on {{{pyOpenSSL}}} directly), but Tahoe-LAFS's build scripts are guaranteed to be executed with setuptools present, so we can at least make it work for all users that way.