Decide fate of apptools.naming

[corranwebster]

This is an implementation of the Java Naming and Directory Interface - or at least the naming part of that - with specific implementations for a hierarchy of Python objects and for file system stores. It is used by Mayavi, but possibly only as part of the Wx backend.

It is intended to provide a standard API for hierarchical namespaces that standard interfaces can then build on top of, but I have a suspicion that at least some of the code that duplicates the Java APIs is over-engineered for Python (eg. the InitialContextFactory object feels very much like it could just be a callable).

If it is to be kept, then there are some improvements that should be made:

• it has its own adapter system; this should be converted to use standard Traits adaptation
• the pyfs_context seems of limited utility for Enthought and insecure by default (since it uses pickles); a JSON-backed version might make more sense if it is needed at all
• perhaps split out implementations from abstract/base classes
• separate out the UI components and fix them up (see Apptools naming UI is Wx-only #138)
• generally clean-up the codebase.

[aaronayres35]

Coverage report on naming from running the full test suite:

[kitchoi]

Offline discussion: apptools.naming will be kept (at least for the next release: 5.0) as it is being used downstream (e.g. mayavi).

[kitchoi]

it has its own adapter system; this should be converted to use standard Traits adaptation

That adapter system is removed as part of #219

Offline discussion: apptools.naming will be kept (at least for the next release: 5.0) as it is being used downstream (e.g. mayavi).

I think when we drew this conclusion, we had not explored in details the functionality offered by apptools.naming.ui.api.explore.

Through #219, we now have a better understanding as to what apptools.naming.ui.api.explore does.

From Mayavi2 in a Python 2.7 + wxPython 3 environment (the explore function does not work with wxPython4 or Qt as of pyface 7.1.0):

EDM dependency

appdirs            1.4.3-1     enthought/free
apptools           4.5.0-2     enthought/free
configobj          5.0.6-3     enthought/free
curl               7.58.0-1    enthought/free
distribute_remove  1.0.0-4     enthought/free
envisage           4.8.0-3     enthought/free
hdf5               1.10.5-8    enthought/free
lib_netcdf4        4.3.3.1-11  enthought/free
libjpeg            7.0-5       enthought/free
liblzma            5.2.4-2     enthought/free
libpng             1.6.36-5    enthought/free
libtiff            4.0.10-4    enthought/free
libxml2            2.9.7-1     enthought/free
mayavi             4.7.1-5     enthought/free
mkl                2018.0.3-2  enthought/free
numpy              1.15.4-2    enthought/free
packaging          16.8-3      enthought/free
pip                18.1-1      enthought/free
pyface             6.1.2-3     enthought/free
pygments           2.2.0-1     enthought/free
pyparsing          2.2.0-1     enthought/free
setuptools         38.2.5-2    enthought/free
six                1.11.0-1    enthought/free
traits             5.1.2-1     enthought/free
traitsui           6.1.3-2     enthought/free
vtk                8.1.2-1     enthought/free
wxpython           3.0.2.0-7   enthought/free

The definitions of the objects can be seen in the Python shell behind the top window. The top window is launched when I type explore(person).

Instead of seeing the value directly, I need to drag and drop a node onto the Python prompt to see the value. But say I drag and drop child, which is supposed to be an instance of Child on Person, I get a PyContext object instead of an instance of Child. The mapping dictionary is also confusing to read, neither does it show all the nested values, because the adapter for trait dict is not actually applied.

Personally I find the functionality somewhat underwhelming, but maybe there are other useful capabilities yet to be found.

[kitchoi]

Further offline discussion:

• apptools.naming.ui can be removed because only the explore function is used in mayavi and nowhere else. The import in mayavi has import errors being guarded against such that removing explore won't break the application. As mentioned above, its utility is also questionable.
• The non-UI component of apptools.naming are depended on in other places via imports, e.g. (not exhaustive) here, here, so they have to be kept (for now at least).

[rahulporuri]

Closing this issue now as the fate of apptools.naming has been decided and apptools.naming.ui has been removed.