Add dependency graph to README

[giopaglia]

We need a public dependency graph for the project. This is a first attempt.

[alberto-paparella]

I agree that a dependency graph would be of great value. I checked the dependencies and didn't notice any inconsistencies. Probably, if you move SoleFeatures.jl on the right side there won't be any arrows overlapping and it would make the graph even more clear.

[mauro-milella]

I agree with @alberto-paparella, so I tried to play with mermaid to force SF node to stick on the right.

It seems to me that forcing these behaviors in mermaid is very unintuitive, so I opted for a solution that takes advantage of subgraphs. Perhaps this is easier to maintain?

Tell me what you think, for now README contains both @giopaglia and mine version.

[alberto-paparella]

Thanks @mauro-milella. I feel like the second version is more clear.

[giopaglia]

Wow @mauro-milella , the second one is beautiful!
(Maybe we can experiment with taking Sole out of that subgraph and hoping it is positioned in the middle)
Then I would suggest adding formatting for signaling that the following packages are registered and usable:

• SoleBase
• MultiData
• SoleLogics
• SoleData
• SoleModels
• Sole
• ModalDecisionTrees

The formatting could consist of making the text bold, italic, underlined, or may have to do with a particular border style for these nodes.

Now, there is still something missing: Audio911.jl and SoleAudio.jl; but those two packages are not usable and we are not actively mantaining them, @PasoStudio73 should we add them here or not? Maybe we should add Audio911.jl as a dependency for SoleFeatures.jl? With the idea that SoleAudio in the future will be an extension of SoleFeatures.

Do you people have thoughts? Thx

[mauro-milella]

The idea of adding signs (and a legend) is super nice!
For now I just moved Sole.jl node in the middle.

I leave the floor to paso for the considerations about SoleAudio.

[ferdiu]

I have some suggestion: I would change the color of the central node (Sole.jl). I feel like it should be different from the three nodes above and, being outside a box, I propose it to be white as the other nodes outside boxes.

The formatting could consist of making the text bold, italic, underlined, or may have to do with a particular border style for these nodes.

I agree with the formatting syntax to specify which of them are solid and which are not. Maybe underline or bold is more visible than italic.

Now, there is still something missing: Audio911.jl and SoleAudio.jl; but those two packages are not usable and we are not actively mantaining them, @PasoStudio73 should we add them here or not? Maybe we should add Audio911.jl as a dependency for SoleFeatures.jl? With the idea that SoleAudio in the future will be an extension of SoleFeatures.

I think that we should not wait for those packages to be ready to publish the current dependency graph. Instead I suggest to merge this and open a new Issue for

[PasoStudio73]

Now, there is still something missing: Audio911.jl and SoleAudio.jl; but those two packages are not usable and we are not actively mantaining them, @PasoStudio73 should we add them here or not? Maybe we should add Audio911.jl as a dependency for SoleFeatures.jl? With the idea that SoleAudio in the future will be an extension of SoleFeatures.

Do you people have thoughts? Thx

SoleAudio.jl
It's the grandfather of SoleXplorer: it was my original code for automate audio related experiments, but then, we move forward to SoleXplorer.
I think we can skip SoleAudio and mark it as archived.
There's some interesting code inside that I could move into Audio911.

Audio911.jl
Actually this package lives outside Sole realm. It's audio related: it takes audio signal on input and gives features on output.
I think there's no real dependencies between Audio911 and SoleFeatures: Audio911 can feed SoleFeatures: this package should be intended only for features analyzing, not for features extraction, I think.

[giopaglia]

Great! This will do for now.
Little sidenote: while this is not displayed in the graph, SoleModels actually depends on SoleData.

However, it only depends on SoleData because of a convenient method that calls scalarlogiset automatically:

SoleModels.apply(x::AbstractModel, a_dataset_of_anytype, args...; kwargs...) = SoleModels.apply(x, SoleData.scalarlogiset(a_dataset_of_anytype), args...; kwargs...)

This is useful when one wants to apply a symbolic model to a DataFrame directly, for example, without having to call scalarlogiset explicitly.
In principle, this dependency will go away, as soon as we change "logiset" to be a trait, and not a AbstractLogiset type (as discussed, this is something that should also happen for "symbolic models" and "AbstractModel").

But for now adding an edge SoleModels -> SoleData would only clutter the nice symmetric visualization.

Grazie ragazzi!