On Wed, 08 Jul 2009 09:22:52 -0700, Paul Moore <p.f.mo...@gmail.com> wrote:
If the only driver for this PEP is setuptools, then I'm -1 on it.
Unless someone working on a packaging tool *other* than setuptools (or
setuptools-derived projects) speaks up and says "I have code of my own
which uses distutils, and I would benefit as follows from PEP 376 and
I will be changing my code to conform to PEP 376" I think the PEP
should be rejected, and the energy put into some other PEP which will
benefit the wider (non-setuptools) community.
Other than easy_install/pip, there is also PyPM which is being developed
at ActiveState. PyPM is the Python package manager much like what ppm is
for ActivePerl.
We build packages using 'setup.py install --root', but when it comes
installation on client .. there is a separate database of installed
packages that has the following information for each package installed:
- metadata (name, version, author, etc..)
- installed_files (list of files installed on client)
So "pypm remove Foo" will simply remove all the 'installed_files' of Foo
and remove Foo from the package database. The package database is
currently an sqlite-based one.
PEP 376 definitely will benefit PyPM besides benefiting setuptools/pip. If
all package managers rely on common API to 1) retrieve metadata of
installed packages 2) write metadata into site-packages), then it is very
possible that one package manager does not mess up with the installation
of others. For example:
$ pip install IPython
$ pypm install ipython
Without PEP 376, pypm will overwrite pip's installation. But with PEP 376,
as pip writes the RECORD file, pypm will reuse it (via the API) and
co-operate with it.
Eventually, I'd like PEP 376 to support system packagers too. So for
example, if you did "apt-get install python-pyqt4", then running "pip
install python-pyqt4" should return without installing anything .. as
RECORD will be part of the .deb previously installed. As for generating
the RECORD file, I vote for generating it during install time (w/ absolute
paths).
-srid
_______________________________________________
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
