[tahoe-dev] [tahoe-lafs] #1159: 1.8beta is incompatible with existing node directories due to change of appname

[tahoe-lafs]

#1159: 1.8beta is incompatible with existing node directories due to change of
appname
----------------------------+-----------------------------------------------
     Reporter:  davidsarah  |       Owner:  somebody                                                           
         Type:  defect      |      Status:  new                                                                
     Priority:  critical    |   Milestone:  1.8.0                                                              
    Component:  code        |     Version:  1.8β                                                               
   Resolution:              |    Keywords:  regression test-needed backward-compatibility forward-compatibility
Launchpad Bug:              |  
----------------------------+-----------------------------------------------

Comment (by davidsarah):

 Replying to [comment:1 zooko]:
 > Hm, there are four overlapping namespaces here.
 >
 > One is the "appname" which is defined by us (the Tahoe-LAFS project) to
 distinguish different variants or forks of Tahoe-LAFS or independent
 implementations of the LAFS protocol. We agreed on how to do this
 versioning in [http://tahoe-lafs.org/pipermail/tahoe-
 dev/2008-November/000879.html this message to tahoe-dev]. The appname is
 used in [source:src/allmydata/__init__.py at 4597#L61 in
 allmydata/__init__.py] to construct a variable named
 {{{__full_version__}}}, which is used in a few places such as
 [source:src/allmydata/storage/server.py at 4595#L270 storage/server.py]. The
 appname for Tahoe-LAFS has been "allmydata-tahoe" for the last couple of
 years, and we would like to change the appname to "tahoe-lafs" someday.
 >
 > Another namespace is the Python "distribution" namespace. (A
 "distribution" is what the Python world calls a package.) This is a global
 namespace where everyone on the planet is supposed to avoid choosing
 colliding names. An important central locus of this namespace is the
 Python Package Index (which I suppose ought to be called the "Python
 Distribution Index")—installers such as {{{easy_install}}} and {{{pip}}},
 when asked to install a distribution named {{{$DIST}}}, will by default
 look for it at {{{http://pypi.python.org/pypi/$DIST}}}. The distribution
 name for Tahoe-LAFS has been "allmydata-tahoe" and we would like to change
 it to "tahoe-lafs".

 As far as I understood, these were intended to be the same by definition,
 at least for Python implementations of the protocol. I.e. the
 "{{{application-version}}}" field in introduction messages is specifying
 the implementation version (''not'' a protocol version), and the
 distribution string is also specifying the implementation version, and so
 we put the latter string into {{{application-version}}}. (Clearly there
 can be non-Python implementations of the protocol, and they would use
 whatever is the nearest equivalent of the distribution string.)

 Is there any reason for these not to be the same by definition, for Python
 implementations?

 > The third namespace is the Python "package" namespace. (A "package" is
 what the Python world calls a directory containing an {{{__init__.py}}}
 file.)

 No, absolutely not! That's the '''module''' namespace. A package is
 something else entirely; see below.

 (Okay, much of the Python world may be inconsistent in the terminology
 they use, but the official docs are consistent on this point.)

 > Now currently [source:trunk/setup.py at 4616#L329 our build scripts] ensure
 that the Python distribution name is always equal to the appname,

 More precisely (and it's important to be precise here), a distribution is
 named by {{{appname+'-'+version}}}. The things named by an {{{appname}}}
 alone are called "packages" (hence "Python Package Index"). A distribution
 contains a particular version of a package.

 (Packages are also called "projects" in some of the [http://tahoe-
 lafs.org/trac/zetuptoolz/browser/trunk/pkg_resources.txt setuptools
 documentation], but no-one uses that, not even the rest of the setuptools
 docs and code.)

 > and the [source:src/allmydata/scripts/create_node.py at 4641#L31 create-
 node command] adds {{{pkg_resources.require(APPNAME)}}} to the {{{tahoe-
 client.tac}}} file.
 >
 > The fourth namespace is the scripts and executables in your system,
 where we currently create a file named {{{tahoe}}}.
 >
 > One thing that we can do right away to ease this is change create-node
 to stop putting the call to {{{pkg_resources.require()}}} in the tahoe-
 client.tac.

 As far as I understand, the ostensible purpose of that call is to ensure
 that when we import modules named {{{allmydata.*}}}, we're getting them
 from some version of the {{{allmydata-tahoe}}} package (this doesn't help
 to ensure that we're getting the right version). On the other hand, I
 don't think it actually succeeds in doing even that, if another package
 defines an {{{allmydata}}} module and happens to be earlier on
 {{{sys.path}}}, which is currently possible. However I think it is also
 necessary in order for the call to {{{load_entry_point}}} in the CLI
 wrapper script to work correctly.

 (The implementation of {{{pkg_resources.require}}} in zetuptoolz is [http
 ://tahoe-lafs.org/trac/zetuptoolz/browser/trunk/pkg_resources.py#L657
 here]. Good luck tracing that :-)

-- 
Ticket URL: <http://tahoe-lafs.org/trac/tahoe-lafs/ticket/1159#comment:2>
tahoe-lafs <http://tahoe-lafs.org>
secure decentralized storage