Reorganization of rsbooster submodules

[JBGreisman]

Right now, the organization of rsbooster is a bit haphazard by virtue of how it was written to distribute distinct scripts. I'd like to reorganize the submodules of the package to better reflect the common tasks. I think the existing scripts could be fit within the following submodules:

• maps: will contain scripts from realspace, diffmaps, and esf
• scaling: will contain scripts from scaleit
• stats: unchanged
• io: will contain what's there now, and what's in utils

I think these 4 submodules are a more coherent organization than the current 7 submodules. Posting this as an Issue to seek feedback before I make any changes -- any thoughts on this?

[kmdalton]

I was going to say that it is useful to have a utils submodule around, but then I looked at what is in the current one.

I think your plan is good, but we may want to resurrect utils in the future if there are utility functions which don't fall under the rs scope.

[dennisbrookner]

I'm going to start on a script for writing R-free flags. Where should that live? Is that a utils type of thing?

[dennisbrookner]

A musing - how would we feel about very slowly, with deprecation warnings, moving the rs.algorithms module into rs-booster? Looking through the current structure of rs and rsb, those seem like the outlier to me, and just ended up in the main rs because rsb didn't exist yet.

I think it would help clarify the structure we're (I think?) going for, where rs is essentially just a robust implementation of the DataSet object, and rsb is more for doing things. Just a thought!

Writing a CLI for the algorithms would be trivial, and makes sense with some of the other command-line utilities found in rsb. And it might even get more folks using them.

[JBGreisman]

I don't think I agree on the distinction between rs and rsbooster. I think of rs as a library, and that it should encompass the pandas parts, but also well-tested implementations of crystallographic methods that operate on parts of DataSet (for example, French-Wilson scaling). As such, I don't think we should deprecate rs.algorithms.

I think of rsbooster as being for implementing useful tools that are more "plug and play" for different applications. The line will begin to blur as we better establish a Python API for rsbooster, but I think that things that certain well-tested implementations like French-Wilson scaling should stay in rs