Work-in-Progress: Modularizing nltools #412
Draft
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Goal
The goal of this PR is prep a new version of
nltoolsthat uses our new packageburnt-ends(currently private during development) as a core dependency for common statistics and utility operations.Why?
It allows up to "lighten up" the core codebase of
nltoolsmaking it more maintainable in the long run. Lower maintenance burden -> more fun 😎 .It also allows us to modularize functionality that we have recapitulated across several different Python libraries written by lab members. E.g. both
pymerandnltoolsrewrite essentially the same numpy-base linear regression routines and could instead depend on a single well-tested library to implement this core functionality (burnt-ends). Then each library can simply right the "wrapping code" around this functionality in API-compatible way without having to sweat the finer details.There's probably a formal development term for this, but it's in essence the loose idea of of "functional core, imperative shell" but across multiple toolboxes rather than within a single toolbox.
When
We hope to have this implemented along with a documentation site for
burnt-endsrather quickly. We're currently targeting a0.5.0release given the substantial installation/dependency change and secondary changes this PR will likely create.Anticipated and unexpected slow downs will be logged in this PR. Currently our only anticipated slow-down is in existing code-areas that lack enough testing coverage for the current functionality of
nltools. In these cases, we will need to generate new test code forburnt-endsrather that simply porting over existing testing code.Proposed Redesign
After
pip install burnt-ends, we intend for functionality to be ported over in a fashion like this:Milestones
0.1.0ofburnt-endsto pypi with extractednltoolsfunctionalitynltoolsGA test-suite installburnt-endsfrom pypi and run (with possible failures)nltoolsGA test suite passes with newburnt-endsdependency structure0.2.0ofburnt-endsto pypi with extractedpymer4functionality0.3.0ofburnt-endsto pypi with extractedneighborsfunctionality@ljchang Let me know if I'm missing anything