On 29 August 2014 04:42, Sean Dague <s...@dague.net> wrote:
> On 08/28/2014 12:22 PM, Doug Hellmann wrote:
>> The problem is that the setuptools implementation of namespace packages 
>> breaks in a way that is repeatable but difficult to debug when a common 
>> OpenStack installation pattern is used. So the fix is “don’t do that” where 
>> I thought “that” meant the installation pattern and Sean thought it meant 
>> “use namespace packages”. :-)
> Stupid english... be more specific!
> Yeh, Doug provides the most concise statement of where we failed on
> communication (I take a big chunk of that blame). Hopefully now it's a
> lot clearer what's going on, and why it hurts if you do it.

So... FWIW I think I've got a cleaner implementation of namespaces
*for our context* - it takes inspiration from the PEP-420 discussion
and final design. It all started when Mike reported issues with testr
to me.


tl;dr: we should stop using pkg_resources style namespace packages and
instead have an effectively empty oslo package that sets up the
namespace, which all namespaced libraries would depend on. With a stub
__init__ in local source trees that adds the site-packages path to
itself automatically, and excluding that file in sdist, it should be
entirely transparent to developers and packagers, with no file
conflicts etc.

This works with the existing pkg_resources namespace packages, lets us
migrate away from the pkg_resources implementation one package at a
time, and we don't need to rename any of the packages, and it works
fine with uninstalled and install -e installed source trees.

We need:
 - a new olso package to introduce a common oslo/__init__.py
(recommended in the pre-PEP420 world)
 - a tiny pbr bugfix: https://review.openstack.org/123597
 - and a patch like so to each project: https://review.openstack.org/123604

I have such an olso package https://github.com/rbtcollins/oslo, if
this sounds reasonable I will push up an infra patch to create it.


Robert Collins <rbtcoll...@hp.com>
Distinguished Technologist
HP Converged Cloud

OpenStack-dev mailing list

Reply via email to