Cory, Yeah, my understanding is that the namespace support in Python 3 is far improved, and there was some support for it in Python 2.7 which still had some unique issues from time to time. I'll play around with it a bit and if I find anything worth mentioning I'll report back. At the very least, it can go into a known issues/limitations list.
Part of the main reasons I offered this as only a mild concern is that I'm not fully aware if oslo had made different choices in how namespaces were being handled that directly impacted the compatibility between python 2 and python 3 and using namespaced projects. Thanks! - Billy On Mon, Nov 23, 2015 at 12:39 PM, Cory Johns <[email protected]> wrote: > Billy, > > I also notice that oslo used the following to define the namespace > packages: > > __import__('pkg_resources').declare_namespace(__name__) > > My reading indicates that the preferred way to handle namespace packages > in Python 2 (which is future-compatible with Python 3) is: > > from pkgutil import extend_path > __path__ = extend_path(__path__, __name__) > > I tested this (https://github.com/johnsca/nspkg) and it seems to address > the issues you had with oslo, even in Python 2. (Note that I did also > manually test the --system-site-packages + virtualenv case, though I didn't > commit that code to test.sh in that repo.) > > This is the approach we've been using with the charms.X namespace, so I'm > optimistic that we won't have the same issues you did with oslo. And, as > noted in my previous email, we'll probably be switching to Python 3 very > soon anyway. However, further testing is always welcome. > > > On Mon, Nov 23, 2015 at 2:01 PM, Cory Johns <[email protected]> > wrote: > >> >> On Mon, Nov 23, 2015 at 1:37 AM, Billy Olsen <[email protected]> >> wrote: >> >>> Secondly, I'm mildly concerned with the namespace of choice (using the >>> shared charms. as the parent namespace). There may be a magical python 3ism >>> that resolves the mixed development + packaged use of common code (think >>> pip, virtualenvs, etc), but there were some issues that the oslo components >>> within OpenStack ran into with a shared common namespace ((some are in a >>> blog here >>> <http://blog.nemebean.com/content/whys-and-hows-oslo-namespace-change>, >>> and the spec to remove the namespaces within the oslo packages is here >>> <http://specs.openstack.org/openstack/oslo-specs/specs/kilo/drop-namespace-packages.html>). >>> As the libraries are broken up, as I believe they should be, we need to >>> make sure we've carefully considered how we expect some of these flows to >>> work and make sure they work (and preferably well). Maybe its not really an >>> issue, but I'd love to be convinced of that. >>> >> >> I do think that namespace package support has been much improved in >> Python 3 (in particular, 3.3 and above), but I must admit that I had not >> run into nor been aware of the issues with namespace packages under earlier >> versions of Python. However, there has already been discussion of making >> all layered / reactive charms Python 3 anyway, so maybe we can do some >> quick tests to determine if those issues have been resolved with the new >> namespace package support? >> > > -- Billy Olsen [email protected] Software Engineer Canonical USA
-- Juju mailing list [email protected] Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju
