Comment #3 on issue 275 by [email protected]: Incorrect installation
with setup.py breaks local override
http://code.google.com/p/protobuf/issues/detail?id=275
This is intended and correct behavior for installs using --root and
namespace packages.
A --root install is not something that's supposed to be run where you
install it; --root installs are for making system packages like rpms or
msi's or what-have-you, that will then be actually installed to a final
target location.
In the case of a namespace package, this means that __init__.py for
namespace packages can't be included in the install, as it would create
installation conflicts when you install more than one RPM (or whatever) for
the same namespace package. (See PEP 382 for more background.)
Setuptools works around this by using .pth files to replace the
__init__.py, but the tradeoff is that the directory where the package is
installed *must* support loading of .pth files by Python.
When you install a project without using --root, the install process checks
that the target directory does in fact support .pth files, but this check
isn't done with --root because by definition, a --root install is not going
to be used as-is -- it's going to be chrooted or packed up in some sort of
archive and then installed.
(That's why you're not getting any warnings -- as far as setuptools is
concerned, everything's fine, because /usr/lib64/python2.6/site-packages/
*is* a .pth-supporting directory, and it's expected that when you actually
use the install, you'll be running it from there, *without* the /x in front
of it.)
So, what it boils down to is that either you need to stop using --root, or
else you need to configure your Python to process .pth files in the
/x/usr/lib64/python2.6/site-packages directory (where /x is your --root).
You can do this with:
site.addsitedir('/x/usr/lib64/python2.6/site-packages')
Which will also add the directory to sys.path. (In other words, you can
just change your test code to add the path this way.)
Another option is that if you're using --root in order to avoid the use of
an .egg directory or file, you could perhaps use the 'pip' tool instead,
maybe with a virtualenv. virtualenv and pip are well-established tools for
creating isolated environments with local overrides to systemwide packages,
without using .egg files or directories.
Either way, however, I'd personally just avoid using --root in the first
place; it's really not intended that you'd ever directly use a distutils
--root install for *anything* except building an installation archive,
chroot jail, or symlink farm. That's what it's always been for in
distutils, and setuptools doesn't change that.
In summary, your options are (from least change to most):
* Use site.addsitedir() instead of just tacking the dummy site-packages on
sys.path
* Stop using --root and just install .egg(s) to a temporary directory on
PYTHONPATH
* Use pip and virtualenv (without --root)
By the way, please note that I don't normally respond to direct emails for
support requests on setuptools; in future please use the normal mailing
list (distutils-sig) and bug tracker ( http://bugs.python.org/setuptools/ )
contact channels, so that the information is available for others to see
and search as well. Thanks!
--
You received this message because you are subscribed to the Google Groups "Protocol
Buffers" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/protobuf?hl=en.
