search

JuliaStats / MLBase.jl

A set of functions to support the development of machine learning algorithms
MIT License
185 stars 63 forks source link

Move package to JuliaML #53

Closed CarloLucibello closed 2 years ago

CarloLucibello commented 2 years ago

As per the discussion in https://github.com/JuliaML/MLUtils.jl/issues/2 and specifically @nalimilan's comment, we would like to move this package to the JuliaML org and repurpose it for our needs if that's ok with you people

ararslan commented 2 years ago

If someone can add me to JuliaML then I can facilitate the transfer.

CarloLucibello commented 2 years ago

Actually, we are more inclined to stick with MLUtils now. But I still think it's good for us to adopt this package for future use.

I just noticed that I'm member but not owner in the org. @juliohm could you give @ararslan and me ownership rights?

juliohm commented 2 years ago

I just added you both as owners in JuliaML.

It would be nice to have a deprecation plan for the existing packages in JuliaML that have been superseded by MLUtils.jl. In particular, we should unpin the repositories in the org and add a sentence to the README pointing to the new unified MLUtils.jl package. That will save a lot of headache for new Julia users.

Also, do we already have a clear scope for MLBase.jl and MLUtils.jl? Wouldn't make sense to merge the two and LearnBase.jl and make a single package with core utilities and conventions?

CarloLucibello commented 2 years ago

It would be nice to have a deprecation plan for the existing packages in JuliaML that have been superseded by MLUtils.jl. In particular, we should unpin the repositories in the org and add a sentence to the README pointing to the new unified MLUtils.jl package. That will save a lot of headache for new Julia users.

I'll do all of that when I register MLUtils

Also, do we already have a clear scope for MLBase.jl and MLUtils.jl? Wouldn't make sense to merge the two and LearnBase.jl and make a single package with core utilities and conventions?

yes, that's the plan. I think it will be more appropriate to call MLUtils the package subsuming LearnBase, MLDataPattern, MLLabelUtils, MLDataUtils, and absorbing the DataLoader and some utility functions from Flux. We can reserve MLBase for the future should we feel the need for a "namespace only" package in the StatsAPI style.

As for the current content of this package, I think it can be entirely discarded since it hasn't ever been used and partially overlaps what we already have (or will have) in MLUtils