do we really need python-box?

[sem-geologist]

I was very positive about IO library separation from Hyperspy as its requirements grew up so much. I always look to use less of external libraries for something simple. python-box looks for me some pain for little gain and trouble guarantied in the future.
I see it is kind of drop-in replacement to DictionaryTreeBrowser. Is it really so trivial to have dot notation just to access few attributes, AFAI looked to implementations using it, it is used to create the box, but in the end pure dictionary is returned. Please bear in mind, that python-box officialy declares that it is breaking api with every major release.

What is gain of python-box that this library need it? and why we could not do without it?

personally I liked the mapping idea (mapping one dict/list structures to other (metadata), as is used in tiff and bruker implementations). For me dictionarization of xml or other tree data of significant nodes in oem metadata-structures looks more future proof (less to break). Am I missing something?

I also see it kind of strange that tifffile is optional dependency where python-box is hard requirement. I would understand benefits of pyhton-box if it would be used in Hyperspy's to remake DictionaryTreeBrowser around that. Those objects live during using the software and dot notation access to metadata makes sense as is exposed to user. In case of this library this looks just to give minute shortcut for few developers, but user in end software anyway gets dictionary which is converted to some end form. these created box'es does not live to reach the end-user. Tiff on the other hand is one of the most common formats which many vendors allows to save processed data alongside some propretary formats.

[ericpre]

Please bear in mind, that python-box officialy declares that it is breaking api with every major release.

Yes, we need to pin accordingly.

What is gain of python-box that this library need it? and why we could not do without it?

It is simply used as a drop-in replacement of DictionaryBrowserTree to remove the dependence on hyperspy. If you have alternatives, it would be interesting.

It should be possible to make more library optional, for example: h5py, imageio, scipy, sparse, since only a few reader will use them.

[sem-geologist]

I need to apologize, indeed box is not so bad as initially I had thought. And it has no dependency hell (at least currently looks so). I tend to aggressively attack redundant (not bringing any benefit) dependencies, and this time because it broke something I was extremely annoyed. When some time ago I was advocating to remove dependency from DictionaryTreeBrowser I meant to remove it, not to be replaced. I mean the IO library should be as simple as possible and introduce as least dependencies and should have absolutely no visualization content (for CLI too). Especially that I previously saw things being loaded, being reformed in DictionaryTreeBrowser objects and then returned as dict/list structures, which again by core Hyperspy, when making into signal was taking the same metadata and making again the DTB kind of objects... Which just introduce unnecessary delay. DTB and Box is nice for end or middle user, but In my opinion if it is possible to avoid - it should be avoid for faster file loading times.

As an example look #107 . the import of Box was injected, the part of metadata is being boxified, and returned as boxified. boxification benefits are even not used anywhere later in the code, and is only for JeolX tiffs. It would work perfectly fine without boxification (if tests requires boxified metadata, it should boxify it itself). The thing is creating inconsistancy.

I had made inline review of code in #107 but looks my complain about the unnecessary scruff added was dismissed without any feedback.

I also think what scipy is doing in the dependancies... should any interpolations be of concern of IO library? it is very clear that h5py, imageio, sparse are involved in reading/writing (from segmented/continuous persistent memory device to segmented/continuous temporary RAM)

[CSSFrancis]

I'd agree that removing scipy is fairly low hanging fruit and would do a lot to remove extra dependancies.

[ericpre]

If this is be possible to remove it completely or make it optional, that would be great! Last time I checked, IO code was still part of hyperspy and it was a pain to remove it, now that the IO code is more independent, it may be much easier.

I had made inline review of code in #107 but looks my complain about the unnecessary scruff added was dismissed without any feedback.

Yeah, it seems that this comment disappear, not sure if this is a github glitch...