Disintegration of MLJBase (discussion and tracking issue)
Nobody has claimed this yet.
- Dominant language
- Julia
- Stars
- 163
- Forks
- 46
- Avg merge
- 1d 18h
- Merged PRs (30d)
- 5
Description
It seems there is a case to be made for further modularisation of MLJBase. These all sound reasonable to me but happy to hear other ideas:
-
Separate MLJSerialization (see #388); relevant code lives here: https://github.com/alan-turing-institute/MLJBase.jl/blob/d377bee1198ec179a4ade191c11fef583854af4a/src/machines.jl#L656
-
Separate MLJOpenML; code: MLJBase/src/openml.jl
-
Separate
UnivariateFinite packageCategoricalDistributions.jl ; code: src/univariatefinite.jl -
Separate StatisticalMeasures package; code: src/measures/
-
Separate MLJComposition package; code: src/composition
The benefits of the 3rd has come in Soss.jl integration but also for models wanting to specify UnivariateFinite distribution priors as hyper-parameters (originally BayesianLDA was this way). The third because it's so big.
Contributor guide
No contributing guide indexed for this repository
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start by reviewing the tracking checklist and the existing code under src/composition. Read the discussion to understand the proposed MLJComposition package boundary and how the completed extractions were handled. Done means separating the composition code into its own package, with the required integration and tests preserved.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- julia
- Domain
- machine-learning
- Issue type
- Refactor
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 25/100