[Ecosystem-engineering] The future of Charm Helpers

[Billy Olsen]

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 <cory.johns at canonical.com>
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 <cory.johns at canonical.com>
> wrote:
>
>>
>> On Mon, Nov 23, 2015 at 1:37 AM, Billy Olsen <billy.olsen at canonical.com>
>> 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

billy.olsen at canonical.com
Software Engineer
Canonical USA
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ubuntu.com/archives/juju/attachments/20151123/ecb6b9b3/attachment.html>