[Distutils] PEP 376 comments

[Ronald Oussoren]

I have some feedback on PEP376, both the pep itself and the pkgutil  
code. I'll start with comments on the PEP.

* I don't like the definition of a project: this seems to define what  
distutils calls a distribution, and that is not necessarily and  
application.

* The description of the status quo is not entirely acurate w.r.t.  
setuptools, you describe only one of the possible ways setuptools can  
install a project (pip seems to use another one of setuptools' ways of  
installing a project, and setuptools can also install projects inside  
of zipfiles in multiple ways).

* Regarding the RECORD file: it is not a "CSV-like" file, it is a real  
CSV file. I'd specify the exact options for the 'csv' module that will  
be used, rather than writing that the default options are used and  
then explaining what those are.

* Should the PEP specify the encoding of text-files? PEP314 doesn't  
seem to specify the encoding of PKG-INFO files, which can cause  
problems when a field contains data that isn't ASCII.


All of these are minor issues. The following are imho more serious.

* The PEP doesn't describe how this PEP interacts with PEP302. That  
is, how should the "egg-info" machinery work when a project is not  
installed on the filesystem but in a zipfile. I'm not primarily  
interested in the ".egg" zipfiles that setuptools uses, but I am  
worried about how this will affect tools like py2exe and py2app that  
bundle the python code used by an application into a zipfile.

* Why is there a "paths" argument for the global functions (such as  
"get_file_users")? The description claims the functions will use  
sys.path and hence it is not necessary to have an argument to specify  
the path.

* There is no API to list the files in the egg-info directory, you  
could build one yourself on top of the get_installed_files method but  
should IMO be part of the public API.


And now on to the implementation:

* EggInfo.get_file: the implementation seems to want to load a file  
from the .egg-info directory, the PEP itself is unclear about what  
this method is intended to do.

If get_file should open a file in the egg-info directory I'd raise an  
exception if the path argument specifies an absolute path.

I wonder if it wouldn't be better to have a function that returns the  
contents of the file instead of one that returns a file-like object.  
Especially when thinking of PEP302 integration.

Wouldn't it be better to have two separate methods instead of "binary"  
argument.  In 3.x file-like objects behave slightly different w.r.t  
binary and text stream ("bytes" vs. "str" as the result of read).

* EggInfo.get_installed_files: if 'local' is True the yielded paths  
are made absolute w.r.t. the egg-info directory rather than the  
directory containing the egg-info directory.

* The global functions seem to maintain and modify global state,  
wouldn't this cause problems if I specify different values of the path  
arguments in different pieces of code?


Ronald