At 06:06 PM 5/16/2009 +0200, Tarek Ziadé wrote:
Ok I've changed the PEP with all the points you mentioned, if you want
to take a look.
Some notes:
1. Why ';' separation, instead of tabs as in PEP 262? Aren't
semicolons a valid character in filenames?
2. "if the installed file is located in a directory in site-packages"
should refer not to site-packages but to the directory containing the
.egg-info directory.
3. get_egg_info_file needs to be specified as using '/'-separated
paths and converting to OS paths if appropriate. There's also the
problem that the mode it opens the file in (binary or text) is unspecified.
4. There should probably be a way to iterate over the projects in a
directory, since it's otherwise impossible for an installation tool
to find out what project(s) "own" a file that conflicts with
something being installed. Alternatively, reshaping the file API to
allow querying by path as well as by project might work.
5. If any cache mechanisms are to be used by the API, the API *must*
make it possible to bypass or explicitly manage that cache, as
otherwise installation tools and tools that manipulate sys.path at
runtime may end up using incorrect data.
6. get_files() doesn't document whether the yielded paths are
absolute or relative, local or cross-platform, etc.
I need to find back your comments for this part, I must have missed
them. That's
the last part I didn't work out yet on the current PEP revision.
Well, if you can't find them, the EggFormats doc explains how these
file/dir structures are currently laid out by setuptools,
easy_install, pip, etc., and the PEP should probably reference that.
Technically, this PEP doesn't so much propose a change to the
EggFormats standard, as simply add a RECORD file to it, and propose
stdlib support for reading and writing it. So, the PEP really should
reference (i.e. link to) the existing standard. The EggFormats doc
in turn cites pkg_resources doc for lower-level format issues, such
as name and version normalization, filename escaping, file parsing, etc.
This PEP should also probably be framed as a replacement for PEP 262,
proposing to extend the de-facto standard for an installation
database with uninstall support, and blessing selected portions of
the de facto standard as an official standard. (Since that's pretty
much exactly what it is.)
_______________________________________________
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
