On Sat, Feb 6, 2010 at 5:42 AM, David Cournapeau <courn...@gmail.com> wrote: > On Sat, Feb 6, 2010 at 1:33 PM, P.J. Eby <p...@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 -- Regards Tarek -- Tarek Ziadé | http://ziade.org _______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
