issues with namespace packages on Debian Squeeze and Python 2.6
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi. It seems I'm having some trobles with setuptools and namespace packages under Debian Squeeze and Python 2.6. One thing to say about Python 2.6 on Debian Squeeze is that "local" packages are installed under /usr/local/lib/python2.6/dist-packages/. I have tried with system default python 2.5, and namespace packages works. The same when I create a virtual environment with python 2.6. The problem seems to just be with system default python 2.6. I'm using the original setuptools (installed from sources), and not the one provided by Debian. Before trying to dig more into the issue, I would like to know if someone else is experiencing the same problem. Thanks Manlio -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk1wELgACgkQscQJ24LbaUTtNwCfe5tj21cHc2IpDbDQShoJ+7zb ml8AoI0h9IKuScKE/mZIkKZGbFC5ILka =0sg2 -----END PGP SIGNATURE-----
On Mar 03, 2011, at 11:05 PM, Manlio Perillo wrote:
It seems I'm having some trobles with setuptools and namespace packages under Debian Squeeze and Python 2.6.
Can you be more specific about what problems you're having?
One thing to say about Python 2.6 on Debian Squeeze is that "local" packages are installed under /usr/local/lib/python2.6/dist-packages/.
I think I explained the reason for this about 5 times at Pycon yesterday, meaning it's probably time to blog about it. :)
I have tried with system default python 2.5, and namespace packages works. The same when I create a virtual environment with python 2.6. The problem seems to just be with system default python 2.6.
I'm using the original setuptools (installed from sources), and not the one provided by Debian.
Yes, I think this is going to give you problems because it doesn't know about dist-packages, and site-packages is not on sys.path by default in the system Python. Please try again with the Ubuntu setuptools package (which is really distribute). It's been modified to know about dist-packages. -Barry
On 11-03-11 14:27, Barry Warsaw wrote:
I have tried with system default python 2.5, and namespace packages
works. The same when I create a virtual environment with python 2.6. The problem seems to just be with system default python 2.6.
I'm using the original setuptools (installed from sources), and not the one provided by Debian. Yes, I think this is going to give you problems because it doesn't know about dist-packages, and site-packages is not on sys.path by default in the system Python. Please try again with the Ubuntu setuptools package (which is really distribute). It's been modified to know about dist-packages.
Note that this debian-specific behaviour also "ruins" other things: buildout 1.5+ can detect system-wide installed eggs and use them if you tell it to. Handy if you want to use stuff like mapnik and so with lots of dependencies. Only: buildout cannot detect the eggs in their non-standard locations as buildout obviously doesn't have the ubuntu setuptools' fix... Do you know any way around this? I'm stuck with buildouts below 1.5 for the time being! Reinout
On 03/22/2011 06:50 AM, Reinout van Rees wrote:
On 11-03-11 14:27, Barry Warsaw wrote:
I have tried with system default python 2.5, and namespace packages
works. The same when I create a virtual environment with python 2.6. The problem seems to just be with system default python 2.6.
I'm using the original setuptools (installed from sources), and not the one provided by Debian. Yes, I think this is going to give you problems because it doesn't know about dist-packages, and site-packages is not on sys.path by default in the system Python. Please try again with the Ubuntu setuptools package (which is really distribute). It's been modified to know about dist-packages.
Debian/Ubuntu's setuptools package has been modified to _install into_ dist-packages in /usr/local, but it has no control over sys.path. Putting dist-packages onto sys.path is handled by Debian/Ubuntu modifications to the site.py in the Python standard library; it isn't affected by which setuptools you use. That said, I haven't looked into the specific problem with namespace packages - it's still possible that using the Debian/Ubuntu setuptools package to install the namespace packages might solve that.
Note that this debian-specific behaviour also "ruins" other things: buildout 1.5+ can detect system-wide installed eggs and use them if you tell it to. Handy if you want to use stuff like mapnik and so with lots of dependencies.
Only: buildout cannot detect the eggs in their non-standard locations as buildout obviously doesn't have the ubuntu setuptools' fix...
This sounds more likely to be caused by not having the site.py changes I mentioned above. IIRC buildout 1.5 uses "python -S" to avoid the automatic import of site.py, so it would never see the Debian/Ubuntu modifications in site.py. As long as buildout uses "-S", I think the only fix for that would be for buildout's "detect system-wide eggs" feature to add in explicit workaround/support for dist-packages. This is what virtualenv does. Carl
On 22-03-11 18:57, Carl Meyer wrote:
Only: buildout cannot detect the eggs in their non-standard locations as
buildout obviously doesn't have the ubuntu setuptools' fix... This sounds more likely to be caused by not having the site.py changes I mentioned above. IIRC buildout 1.5 uses "python -S" to avoid the automatic import of site.py, so it would never see the Debian/Ubuntu modifications in site.py. As long as buildout uses "-S", I think the only fix for that would be for buildout's "detect system-wide eggs" feature to add in explicit workaround/support for dist-packages. This is what virtualenv does.
Just making sure: you're suggesting a debian-specific workaround in buildout? Buildout maintainers: would adding such a workaround be OK with you? Reinout
Maybe not a debian-specific workaround, but a setting like:
[buildout]
additional-site-packages =
/usr/lib/python2.6/dist-packages
/usr/local/lib/python2.6/dist-packages
On Wed, Mar 23, 2011 at 14:42, Reinout van Rees
On 22-03-11 18:57, Carl Meyer wrote:
Only: buildout cannot detect the eggs in their non-standard locations as
buildout obviously doesn't have the ubuntu setuptools' fix...
This sounds more likely to be caused by not having the site.py changes I mentioned above. IIRC buildout 1.5 uses "python -S" to avoid the automatic import of site.py, so it would never see the Debian/Ubuntu modifications in site.py. As long as buildout uses "-S", I think the only fix for that would be for buildout's "detect system-wide eggs" feature to add in explicit workaround/support for dist-packages. This is what virtualenv does.
Just making sure: you're suggesting a debian-specific workaround in buildout?
Buildout maintainers: would adding such a workaround be OK with you?
Reinout
_______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
On Wed, Mar 23, 2011 at 9:42 AM, Reinout van Rees
On 22-03-11 18:57, Carl Meyer wrote:
Only: buildout cannot detect the eggs in their non-standard locations as
buildout obviously doesn't have the ubuntu setuptools' fix...
This sounds more likely to be caused by not having the site.py changes I mentioned above. IIRC buildout 1.5 uses "python -S" to avoid the automatic import of site.py, so it would never see the Debian/Ubuntu modifications in site.py. As long as buildout uses "-S", I think the only fix for that would be for buildout's "detect system-wide eggs" feature to add in explicit workaround/support for dist-packages. This is what virtualenv does.
Just making sure: you're suggesting a debian-specific workaround in buildout?
Buildout maintainers: would adding such a workaround be OK with you?
I abhor screwing w site.py, but buildout is already doing so. I believe it copies site.py so it *should* work with debian modifications. I don't really understand this code and honestly don't want to. It was contributed by someone at and for Ubuntu so I'd expect it to work with debian. I would submit a bug report and hopefully, they'll look at it. In the long term, I'd really like to move this (site.py copying) code out of buildout into recipes, as I don't want to maintain it. In the longer term, I'd love this to get addresses by the pythonv work somehow. :) Jim -- Jim Fulton http://www.linkedin.com/in/jimfulton
participants (6)
-
Barry Warsaw -
Carl Meyer -
Jim Fulton -
Leonardo Rochael Almeida -
Manlio Perillo -
Reinout van Rees