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 #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.