On Sat, Feb 6, 2010 at 8:26 PM, Tarek Ziadé <[email protected]> wrote: > On Sat, Feb 6, 2010 at 5:42 AM, David Cournapeau <[email protected]> wrote: >> On Sat, Feb 6, 2010 at 1:33 PM, P.J. Eby <[email protected]> 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
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 http://mail.python.org/pipermail/distutils-sig/2009-December/014994.html 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. David _______________________________________________ Distutils-SIG maillist - [email protected] http://mail.python.org/mailman/listinfo/distutils-sig
