[Distutils] PEP 376 - RECORD file / Data files + pip feedback ?
cournape at gmail.com
Tue Feb 9 11:20:53 CET 2010
On Sat, Feb 6, 2010 at 8:26 PM, Tarek Ziadé <ziade.tarek at gmail.com> wrote:
> 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
>>> 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
> I still have that in mind. In fact one of the sprints task in Pycon
> could be to create
> a configure command for distutils
Could you expand on that ? I don't understand the link between
configure and the topic at hand ?
> 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
Maybe we are not speaking about the same thing. I was talking about this thread
Having a workable specification for this should not require any heavy
distutils refactoring. As it is mostly reimplementing a known and
already-used design, it should not be a lot of work.
More information about the Distutils-SIG