[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 davidsarah):

 Replying to [comment:5 zooko]:
 > Replying to [comment:2 davidsarah]:
 > > Replying to [comment:1 zooko]:
 [...]
 > > > 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 meant that the python.org docs are consistent in ''not'' using "package"
 when they mean "module" (at least I haven't seen any counterexamples on
 python.org).

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

 OK, that's not too bad.

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

 Gahh. This is completely wrong and unnecessarily confusing. Pretend they
 didn't say that.

 The right term for the latter concept is "module directory".

 (Module code can also be stored in zipfiles, so this isn't necessarily a
 directory in a filesystem.)

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

 I've no objection to using "project", if you think "package" is ambiguous.

 > [...] 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.

 The strings specifying a package/project possibly with a version
 constraint, e.g. "allmydata-tahoe>=1.7.0", are called "requirements".

 > 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"?)

 The argument to {{{pkg_resources.require}}} is a requirement. In this case
 it is just a requirement for an unspecified version of the {{{allmydata-
 tahoe}}} project, which is not all that useful, I think.

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

 I don't ''think'' it actually checks that.

 > It has been a long time since I've felt like I needed that double-check
 and I don't object to removing it.

 Let's try that (for after 1.8.0) and see if it breaks anything.

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