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
nltools
that 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
nltools
making 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
pymer
andnltools
rewrite 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-ends
rather quickly. We're currently targeting a0.5.0
release 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-ends
rather 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.0
ofburnt-ends
to pypi with extractednltools
functionalitynltools
GA test-suite installburnt-ends
from pypi and run (with possible failures)nltools
GA test suite passes with newburnt-ends
dependency structure0.2.0
ofburnt-ends
to pypi with extractedpymer4
functionality0.3.0
ofburnt-ends
to pypi with extractedneighbors
functionality@ljchang Let me know if I'm missing anything