[Ecosystem-engineering] The future of Charm Helpers

[Cory Johns]

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?
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ubuntu.com/archives/juju/attachments/20151123/b01c3001/attachment.html>