On Thu, 05 Nov 2009 14:14:19 -0800, Tarek Ziadé <ziade.ta...@gmail.com>
wrote:
I actually now think that storing the release number inside the
.egg-info/
directory may be a better idea. Like:
$ cat python_ldap-2.3.10.egg-info/pypm.txt
release: 2
$
What do you think?
In that case, an arbitrary file that gets installed in the .egg-info/
directory, that you can read back when needed through the PEP 376
pkgutil new API, seem to be a good idea.
This implies that Python+distutils itself will not be able to
distinguish two different releases that have the same version, but a
different build version.
I assume that the user is not supposed to have two copies of
python-ldap-2.3.10 (but with different release versions) anyway. The
purpose of multiple release version is to provide upgrades to a package
within a single package version.
The *value* of the release version itself is specific to PyPM, of course.
Other binary installers will not have a need for it (they will use their
own format -- see below).
e.g. that just Active State's package manager is able to manage this
extra number.
Yes. And package manager FooBar may use different release number formats,
say, timestamps.
$ foobar install python-ldap
Getting python-ldap_2.3.10_linux_20091023.fbar
FooBar should not read PyPM's release number.
The other option, if this extra binary version number is a generic
need, would be to add a new metadata field in PEP 345. (like in RPMs
IIRC) and build an egg info folder name that contains this extra info
when present.
Since release numbers are specific to the installer (and repository), how
about having it in the .egg-info/INSTALLER file?
$ cat .egg-info/INSTALLER
name: PyPM
[package]
release: 2
url: http://pypm.activestate.com/..../python-ldap....pypm
pinned: True
...
This will also enable adding extra metadata (specific to installer) like
version pinning.
-srid
_______________________________________________
Distutils-SIG maillist - Distutils-SIG@python.org
http://mail.python.org/mailman/listinfo/distutils-sig
