FWIW, let's reference the Python documentation for --prefix: http://docs.python.org/2.7/install/index.html#alternate-installation-unix-the-prefix-scheme
On Nov 30, 2012, at 04:37 PM, Ian Campbell wrote:
>What this bug is about is what happens when I build a 3rd party module
>for use with the system Python using --prefix=/usr.
>
>In this case the modules are installed
>to /usr/lib/python2.7/site-packages/ even though I built against the
>system Python.
>
>This means that the system Python doesn't see the module which I built
>for it.
I can interpret the referenced documentation in two ways.
On first reading of Python's prefix scheme, it seems that using --prefix=/usr
only should indeed install into site-packages.
But the documentation also says this:
Incidentally, the real reason the prefix scheme is important is simply
that a standard Unix installation uses the prefix scheme, but with
--prefix and --exec-prefix supplied by Python itself as sys.prefix and
sys.exec_prefix. Thus, you might think you’ll never use the prefix scheme,
but every time you run python setup.py install without any other options,
you’re using it.
Given that the system Python's sys.prefix and sys.exec_prefix are both /usr,
then you could reasonably expect these two commands to be the same:
$ python setup.py install
$ python setup.py install --prefix=/usr
and of course, they are not. It's not just {dist,site}-packages that are
different but that the former uses /usr/local by default.
>> [2] Which I personally think is a bit suspect since IMHO only Debian
>> packages should be used with the system Python
>
>I wholeheartedly disagree with this. It is entirely reasonable for users
>to want to use a simple 3rd party module with the system Python without
>having to rebuild the whole Python system (including all the modules
>they use which *are* in Debian) from source.
They don't have to rebuild the whole Python system of course. You can use
`virtualenv --system-site-packages` and then just build the special stuff into
the virtualenv. Everything else, you get from the system.
The reason I don't favor installing 3rd party packages into /usr outside of
the packaging system is that it becomes much more difficult to manage your
Python system when you do this. What if you find that the newer Xen (or one
of its automatically installed dependencies) breaks your system? How do you
uninstall things and get back to a clean state?
Sadly distutils doesn't really provide package management support so without
the Debian packaging system, you can't really be certain you've cleaned things
up properly.
In a very real sense then, if you do this, you're own your own, and you
probably have more to worry about than adding --install-layout=deb or removing
--prefix and letting things get installed into
/usr/local/lib/pythonX.Y/dist-packages. As you note, the latter would still
be importable by your system Python, but is definitely much easier to clean
up after.
>> - and why not use virtualenv or a
>> from-source build of Python?
>
>It is unreasonable to expect users to have to build Python from source
>just to do a build of a newer version of Xen (or any other python
>module) than is packaged in Debian.
As I've mentioned, there are other workaround that I would *personally*
recommend (e.g. virtualenv), but one thing is also not clear to me. From your
original bug report:
Removing the --prefix=$(PREFIX) results in installation into
/usr/local/lib/python2.7/dist-packages/ which is in the sys.path (so
correct in that sense) but doing this in the Xen tree removes the
option for people to install Xen to an alternate prefix (e.g. I think
NetBSD uses --prefix=/usr/pkg or some such).
Why couldn't you change the Xen build system to look something like this:
$(PYTHON) setup.py install $(PREFIX)
and leave $PREFIX empty by default? Then you'd get acceptable behavior on
Debian, and leave open the possibility for NetBSD users to provide
`PREFIX=--prefix=/usr/pkg`.
Also, why doesn't NetBSD do the right thing with no --prefix?
signature.asc
Description: PGP signature
