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.


> ---
> 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

Reply via email to