Decide fate of apptools.io

[corranwebster]

This submodule provides a traited File object that provides properties and methods for common file path manipulation operations. Much of this functionality is provided in Python 3 by the pathlib module, and it is not clear what precise benefits this provides, other than notifications of state change. It may be that this is not needed any more. Or it may be that there is some extra functionality which is part of the class, but which could be better handled by using pathlib objects for the duplicated functionality and the File class for everything novel.

There is also apptools.io.h5 which wraps h5py with a dictionary-style mapping. This may end up being superseded by Zarr and similar libraries; but it is likely this code is used by various Enthought applications.

[rkern]

File is mostly used just as a typed representation of a filesystem path, one step above passing around an undecorated string. It's pretty rare that code actually calls the File methods or access many of the derived Property traits. I do see only one place where we listen to changes on the path trait. New code should certainly use pathlib.Path objects instead of File. However, File is fairly woven into a lot of framework code currently.

[aaronayres35]

Coverage report on apptools.io from running the full test suite:

[kitchoi]

Offline discussion: apptools.io will be kept (at least for the next release: 5.0) as it is still being used downstream.

[aaronayres35]

Offline discussion: apptools.io will be kept (at least for the next release: 5.0) as it is still being used downstream.

With this being the verdict, what is the status of this issue? Can we close, or is there still an action to take?

[rahulporuri]

closing this issue as the fate of apptools.io has been decided - it's not going anywhere for now and we also added a short section in the documentation.