On Aug 27, 2014, at 11:55 AM, Donald Stufft <don...@stufft.io> wrote:
>> >> On Aug 27, 2014, at 11:45 AM, Doug Hellmann <d...@doughellmann.com> wrote: >> >> >> On Aug 27, 2014, at 10:31 AM, Sean Dague <s...@dague.net> wrote: >> >>> So this change came in with adding glance.store - >>> https://review.openstack.org/#/c/115265/5/lib/glance, which I think is a >>> bad direction to be headed. >>> >>> Here is the problem when it comes to working with code from git, in >>> python, that uses namespaces, it's kind of a hack that violates the >>> principle of least surprise. >>> >>> For instance: >>> >>> cd /opt/stack/oslo.vmware >>> pip install . >>> cd /opt/stack/olso.config >>> pip install -e . >>> python -m olso.vmware >>> /usr/bin/python: No module named olso.vmware >>> >>> In python 2.7 (using pip) namespaces are a bolt on because of the way >>> importing modules works. And depending on how you install things in a >>> namespace will overwrite the base __init__.py for the top level part of >>> the namespace in such a way that you can't get access to the submodules. >>> >>> It's well known, and every conversation with dstuft that I've had in the >>> past was "don't use namespaces”. >> >> I’ve been using namespace packages on and off for 10+ years, and OpenStack >> is the first project where I’ve encountered any issues. That doesn’t >> necessarily mean we shouldn’t change, but it’s also not fair to paint them >> as completely broken. Many projects continue to use them successfully. > > Just for the record, there are at least 3 different ways of installing a > package using pip (under the cover ways), and there are two different ways > for pip to tell setuptools to handle the namespace packages. Unfortunately > both ways of namespace package handling only work on 2/3 of the ways to > install things. Unfortunately theres not much that can be done about this, > it’s a fundamental flaw in the way setuptools namespace packages work. > > The changes in Python 3 to enable real namespace packages should work without > those problems, but you know, Python 3 only. > > Generally it’s my opinion that ``import foo_bar`` isn’t particularly any > better or worse than ``import foo.bar``. The only real benefit is being able > to iterate over ``foo.*``, however I’d just recommend using entry points > instead of trying to do magic based on the name. Yeah, we’re not doing anything like that AFAIK, so that shouldn’t be a problem. I’m worried about ensuring that upgrades work, ensuring new versions of the existing libs don’t break stable releases, and not having to handle a lot of back ports to separate libraries for things that could otherwise be semver bumps. I’ll spend some time testing to see if we can create a shim layer with the namespace package to avoid some of those issues. Doug > > --- > Donald Stufft > PGP: 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA > > _______________________________________________ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
