[Python-Dev] Relative Package Imports

[Tim Peters]

[Tim, speaks of the devil ...]
> "Something like that" [MAL's __version__ string] needs to be formalized
> and imposed on all public packages.
>
> at-which-point-the-distutils-sig-jumps-in-and-saves-the-day-ly y'rs  - tim

[... and Greg Ward of his legions appears!]
> Been there, tried that, bought the flame war.  I made the mistake of
> kicking off the Distutils SIG back in Decemver with a proposal for a
> standard version numbering scheme for Python module distributions.  See
>
>  http://www.python.org/pipermail/distutils-sig/1998-December/000016.html
>
> for the kick-off of that "heated discussion".  ;-)

Greg, if you call that a flame war, your credentials as an ex-Perl'er are in
serious doubt <wink>.  Except for the cowboy contingent, most participants
were moving swiftly to consensus!

> FWIW, if I was posting that message today, I would s/must/should/ and
> that's about it.

No, it's "must" or it's useless.  What wasn't brought up in that thread is
that the Distutil "version number" is an artficial construct created for the
primary benefit of Distutil tools -- it needn't have anything whatsoever to
do with whatever silly string the developer wants to *display* as being
their "version number".  It's instead a coordinate in an abstract but
rigidly defined Distutil space, specifically designed to make programmatic
navigation of that space reliable in a shared and uniform way.  If a
developer chooses, users need never be exposed to it.  I'd use the x.y.z
Distutil version number directly to keep my own life simpler, but if someone
else wants to display a GUID followed by a 3-letter country code and the
number of nanoseconds since the birth of Mohammed, fine -- they still have
to map that to Distutil VN space internally or write their own stinkin'
disttools.  You may have went overboard on the *semantics* of the Distutil
VN, though:  its only real meaning is in what Distutil tools *do* with it.

Fight this battle again.  Without a uniform way for an installer to *know*
when it's thought safe to replace a package with another version of that
package, Python installations will never move beyond the similar hell of
Windows 3.1.

even-herds-of-cats-wear-collars-ly y'rs  - tim