[Distutils] PEP 376 - RECORD file / Data files + pip feedback ?

Tarek Ziadé ziade.tarek at gmail.com
Sat Feb 6 12:26:28 CET 2010

On Sat, Feb 6, 2010 at 5:42 AM, David Cournapeau <cournape at gmail.com> wrote:
> On Sat, Feb 6, 2010 at 1:33 PM, P.J. Eby <pje at telecommunity.com> wrote:
>> At 06:10 PM 2/5/2010 -0800, Sridhar Ratnakumar wrote:
>>> On 2010-02-05, at 4:57 PM, P.J. Eby wrote:
>>> > At 04:49 PM 2/5/2010 -0800, Sridhar Ratnakumar wrote:
>>> >> Do we have a real-world example for installing uninstallable data files
>>> >> outside sys.prefix?
>>> >
>>> > Scripts aren't always in sys.prefix,
>>> Scripts *usually* go to sys.prefix/bin (or sys.prefix/Scripts or
>>> site.USER_BASE/Scripts). Are their packages that actually put them
>>> elsewhere?
>> It's not the package that determines installation locations, it's the user's
>> command line options and configuration file settings that determine the
>> locations for libraries, scripts, and data files.
>>> > Also make sure you're not forgetting e.g. shared hosting scenarios
>>> > without a virtualenv, unless you're planning to make virtualenvs an
>>> > officially-supported thing.  In such cases, the paths involved won't
>>> > necessarily fall into a single root.
>>> PyPM is an ActivePython tool which installs itself into, say,
>>> /opt/ActivePython-2.6 - a single root directory. So we never had to worry
>>> about other layouts. PyPM supports virtualenvs too, so "pypm -E /tmp/myenv
>>> install lxml" would install into the specified virtualenv.
>>> > Also don't forget sys.exec_prefix.  (Isn't packaging fun?)
>>> In ActivePython, sys.exec_prefix == sys.prefix.
>> Yes, well, as I said, isn't packaging (in the wider Python world, where few
>> such simplifications can be had) fun?  ;-)
> May I remind of my recent suggestion of a build manifest ? It was
> precisely designed to solve this kind of issues, and a similar format
> is used by Cabal for Haskell, which supports a wide variety of install
> scenario as well. It supports relocation.
> I am rather suspicious about attempts of designing such things from
> scratch without looking at how other packaging tools do similar
> things.

I still have that in mind. In fact one of the sprints task in Pycon
could be to create
a configure command for distutils (like what 4suite has) (I've pointed
you to the repo where I am
have started a prototype for this in a recent mail -- we sure could
use your help/knowledge on this if you want
to contribute)

But that's a lot of work that will not happen in 2.7. Here, the
attempt is not to correct distutils design
flaw about building things (e.g. the fact that install is also a build
command in some way), but rather
to find the simplest way to define the RECORD file, whichars is the
latest missing bits to have a PEP that
can be accepted for inclusion in PEP 376 --


Tarek Ziadé | http://ziade.org

More information about the Distutils-SIG mailing list