New package: SossMLJ v0.1.0

[JuliaRegistrator]

• Registering package: SossMLJ
• Repository: https://github.com/cscherrer/SossMLJ.jl
• Created by: @DilumAluthge
• Version: v0.1.0
• Commit: aec0583d143a83d118194bc258d80c876223b3c3
• Reviewed by: @DilumAluthge
• Reference: cscherrer/SossMLJ.jl@aec0583#commitcomment-42345391

[DilumAluthge]

[noblock]

cc: @cscherrer @ablaom @tlienart

[DilumAluthge]

[noblock]

Does anyone object to me merging this before the waiting period has completed? This package integrates the Soss.jl probabilistic programming language into the MLJ.jl machine learning framework, so SossMLJ.jl is the most logical choice for a name.

[github-actions]

Your new package pull request met all of the guidelines for auto-merging and is scheduled to be merged when the mandatory waiting period (3 days) has elapsed.

Since you are registering a new package, please make sure that you have read the package naming guidelines: https://julialang.github.io/Pkg.jl/dev/creating-packages/#Package-naming-guidelines-1

---

If you want to prevent this pull request from being auto-merged, simply leave a comment. If you want to post a comment without blocking auto-merging, you must include the text [noblock] in your comment.

[ablaom]

[noblock]

Mmm. I'm assuming there's a reason you don't include the implementation of the MLJ interface in Soss.jl itself?

At present we do have interfaces that live outside the algorithm-providing package, but the convention for naming is different. For example, we have MLJScikitLearnInterface and will soon have others like MLJMultivariateStatsInterface (see the MLJModels "disintegration" issue). (I admit there is one exception to this rule MLJFlux.)

[DilumAluthge]

[noblock]

Yep, SossMLJ needs some stuff from MLJBase, so it's a little heavier than the average MLJ integration. That's why we decided to keep it in its own package.

I don't feel too strongly about the name. We could also do MLJSoss.

MLJSossInterface feels a little too verbose? But we could do that also.

The Soss+Gen integration is being worked on in https://github.com/cscherrer/SossGen.jl, so SossMLJ is consistent with SossGen.

@cscherrer Any thoughts?

[cscherrer]

[noblock]

I'm not sure if there's a general rule for interfaces across platforms, and this seems to me more Soss-specific than MLJ-specific - much less plug-and-play than most MLJ models. I do like the idea of easy discoverability by tab completion, for the future situation of someone developing models in Soss looking for more opportunities to use it.

[DilumAluthge]

[noblock]

Another consideration is that we are probably going to disintegrate Soss into multiple smaller packages, including:

• Soss
• SossBase
• SossSymPy - we'll be factoring the Python out into this package
• SossMLJ

[ablaom]

[noblock]

Don't have any strong objections to any of the suggested names. My comment was just for context.

[ablaom]

[noblock]

MLJ users won't have problem finding it because it will be in the model registry; the package_name assigned will be Soss (unless there is some reason not to) and a separate trait load_path links to the package with the interface.