Open Stack

On Aug 27, 2014, at 11:55 AM, Donald Stufft <donald at stufft.io> wrote:

>> 
>> On Aug 27, 2014, at 11:45 AM, Doug Hellmann <doug at doughellmann.com> wrote:
>> 
>> 
>> On Aug 27, 2014, at 10:31 AM, Sean Dague <sean at 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 at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev