[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:  major       |   Milestone:  1.8.0                                                   
    Component:  code        |     Version:  1.8β                                                    
   Resolution:              |    Keywords:  test-needed backward-compatibility forward-compatibility
Launchpad Bug:              |  
----------------------------+-----------------------------------------------

Comment (by zooko):

 Replying to [comment:2 davidsarah]:
 > Replying to [comment:1 zooko]:
 > > 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.
 > > Another namespace is the Python "distribution" namespace. (A
 "distribution" is what the Python world calls a package.)

 > 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.)

 Agreed.

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

 I can't think of any at the moment.

 > > 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.)

 What docs are you referring to? I really wish that there was some official
 justification to use "package" to mean a package, but sadly I was unable
 to persuade the distutils-sig mailing list to get behind a full-scale
 renaming. Therefore we are currently stuck with this:

 http://guide.python-distribute.org/glossary.html

 Distribution

     A Python distribution is a versioned compressed archive file that
 contains Python packages, modules, and other resource files. The
 distribution file is what an end-user will download from the internet and
 install.

     A distribution is often also called a package. This is the term
 commonly used in other fields of computing. For example, Mac OS X and
 Debian call these files package files. However, in Python, the term
 package refers to an importable directory. In order to distinguish between
 these two concepts, the compressed archive file containing code is called
 a distribution.

     However, it is not uncommon in Python to refer to a distribution using
 the term package. While the two meanings of the term package is not always
 100% unambigous, the context of the term package is usually sufficient to
 distinguish the meaning of the word. For example, the python installation
 tool pip is an acronym for “pip installs packages”, while technically the
 tool installs distributions, the name package is used as it’s meaning is
 more widely understood. Even the site where distributions are distributed
 at is called the Python Package Index (and not the Python Distribution
 Index).

 > (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.)

 That might be our only hope -- the word "project" isn't already used to
 mean something else within Python, so maybe we could start consistently
 using it to mean all-versions-of the source that is used to produce
 distributions (each of which has a version number).

 By the way I think that Brian in comment:3 is showing that he is confused
 about the difference between distributions (sometimes called packages,
 especially by the rest of the world outside of Python), packages
 (directories that have {{{__init__.py}}} files in them, and modules
 (importable bundles of Python code). The {{{pkg_resources}}} API is
 intended to express a dependency on a project, i.e. a range (possibly
 "any") of versions of distributions of that project. (Note the name begins
 with "pkg", which stands for "distribution". Ha ha.)

 David-Sarah wrote in comment:2:
 > 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

 My purpose in adding that call to {{{pkg_resources}}} was to ensure that
 if the distribution ("package"? "project"?) was not installed that we
 would get an explicit error at that point instead of proceding. Actually,
 it was more to ensure that the transitive closure of the
 {{{install_requires}}} of the {{{allmydata-tahoe}}} distribution were
 installed. It has been a long time since I've felt like I needed that
 double-check and I don't object to removing it.

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