Consider removing Sweeper, PipelineInference, and ResultProcessor assemblies from Microsoft.ML nuget

[eerhardt]

We currently have a few assemblies in our Microsoft.ML nuget package that aren't part of what we want in our public API surface area.

These assemblies include:

• Microsoft.ML.Maml
• Microsoft.ML.ResultProcessor
• Microsoft.ML.PipelineInference
• Microsoft.ML.Sweeper

The last two may some day be part of our public API, but in their current form we don't want to expose them as public API.

We should remove these assemblies from our nuget package (maybe put them in a separate nuget package), so external users don't depend on these types. That way we are free to update the API until we are ready to ship it as an official API.

/cc @Zruty0 @TomFinley

[TomFinley]

Hi @eerhardt thanks for looking at this. I am certain these do not belong in Microsoft.ML package at all, but what I'm less certain about is whether we need to publish any of them in a nuget.

I am fairly confident that the Maml package exists for test support and the console project, and does not need to be in any nuget I believe. But I'd gladly learn better.

Regarding pipeline inference and sweeping, and maybe result processor, @sfilipi might know best about what the current dependency structure is w.r.t. GUI. Some of this code might need to be in a nuget for the sake of that, assuming that the way that consumes these packages is via nuget. But I'm not sure if the GUI actually depends on any of that. @justinormont is I think possibly consuming some of these packages, but how he is doing it (whether by nuget or some other mechanism), I do not know.

Edit: Given that usage, if any, would be for in progress work that would probably be working off master branch anyway, one practical solution would be to remove them from the nuget, see who complains (if anyone), then fix if anyone complains.

[eerhardt]

@justinormont - @TomFinley and I are considering removing the PipelineInference code from dotnet/machinelearning all together. The reasoning is that we don't expect to ship this assembly any time soon, and it is impeding our progress making the new API changes. We currently need to keep it building, running, etc.

If we remove it from the repo, we will have it in the source control history, and can always bring it back when we are ready to ship it.

Thoughts?

[justinormont]

@eerhardt : Can you ping Nader and @abgoswam? I will be out for a week (until ~Sept 4rd).

Removing the PipelineInference code from the codebase would be rather detrimental. One option would be to move it towards the internal repo. In the end, this is required by our GUIs and AutoML system (and another two <redacted> projects).

cc: @markusweimer, who may want to chime in regard to the AutoML project's ongoing status.

[justinormont]

I'd recommend discussing w/ @RagingBull630 (Nader Albussam).

[TomFinley]

Hi @justinormont and @abgoswam , perhaps one of you or someone else could, if you cared, move it out? We might remove it soon, since we're in the process of hiding anything we don't want in the public surface area, especially more experimental work like this.

If we remove it before you get to it, you can of course simply fetch it again from the history to "resurrect" it in a place of your choosing.

[justinormont]

PipelineInference is under active development. Last I talked w/ @chris-lauren we are expecting to move forward and bring this more in to the forefront.

[TomFinley]

That's fine, but if under active development, it seems like that development is not happening in ML.NET anyway -- the changelogs for the associated directories has not seen much progress. It is not part of our public API. Nor would it ever really need to since pipeline sweeping is something that can use ML.NET but doesn't have to be ML.NET, right?

At least searching open or closed issues for PipelineInference reveals nothing about future development. Outside of github, I have seen no mention of it in API reviews (beyond of course the desire to remove it from our repo), nor in the active project lists do I see mention of it. It is not clear to me it is under active development in any meaningful sense of the word.

Feel free to share specific reasons for your request to keep it.

[ganik]

@TomFinley @eerhardt
NimbusML references PipelineInference, and the build is currently breaking:
The type or namespace name 'PipelineInference' does not exist in the namespace 'Microsoft.ML.Runtime' (are you missing an assembly reference?)

Is there anyway I can fix this in NimbusML code?

[eerhardt]

It looks like the whole Microsoft.ML.PipelineInference library was removed with 37176a1.

What specifically does NimbusML use PipelineInference for?

[montebhoover]

Attempting to remove references to PipelineInference and AutoInference...

[Ivanidzo4ka]

@ganik do you know what is current status of PipelineInference in NimbusML?
Can we safely remove this libraries from ML package?

[eerhardt]

NimbusML (or any other consumer) can still use these libraries if we put them in their own NuGet packages. The important piece for this work is that the above assemblies should not be in the Microsoft.ML NuGet package. That package is only for "core" libraries that everyone needs.

[Ivanidzo4ka]

Ok, let's move them to separate Nuget packages (only Sweeper and PipelineInference) and delete 4 projects from Microsoft.ML
@singlis can you take care of this?

[singlis]

Yes - Ill take a look, thank you.