GoSlice as lib to avoid extra binary

[aligator]

Hi,

is there a specific reason you did not use GoSlice as lib? As you licensed SlicerA also AGPL it shouldn't be a problem, as long as you don't ship it directly with aroz and just provide it as extra, downloadable module.

This would make the handling of SlicerA more easy. It would also fix the permission problem I faced.

If it's ok from your side, I would create a PR for it.

[tobychui]

Hi @aligator,

There are a few concerns that I considered when I include GoSlice in SlicerA.

Firstly, as GoSlice is still in its very early experimental phrase as stated in its README

This is a very experimental slicer for 3d printing. It is currently in a very early stage, but it can already slice models:

As any internal functions / API might change at anytime (according to my definition of "very experimental" software), and I am usually busy during the day, it will be hard for me to keep track of your updates in the GoSlice development. Including a binary instead of using it as a go module will be beneficial to anyone who want to build the system and not to deal with compatibility issues in the future even if you have updated the GoSlice API.

Secondly, SlicerA is deigned to be used by myself, and I am not updating the slicer that often if it works perfectly on my machines. So including a binary instead of pulling from 3rd party dependencies every time I want to deploy a new 3D printer make the deployment process more stable / robust in the long run.

I will consider integrating GoSlice directly as a go module into the SlicerA if and only if GoSlice has created its first stable release (in term of internal API / functions and runtime stability).

Feel free to let me know how you think about this arrangement 👍🏻

[aligator]

Hi, good point, but in the end I don't think it's more "more stable / robust" to do it that way:

As any internal functions / API might change at anytime (according to my definition of "very experimental" software)

The experimental is mostly because I am not an expert at creating a slicer and basically everything is done by trial and error. (still, it works quite well for this :-)
And I want to make clear with 'experimental' that you cannot expect the same quality and feature completeness as from e.g. Cura / Prusa Slicer. That won't change until someone who really knows the matter (polygon calculations) helps me. (For example I added the support just by trial and error until it looked like support as I wanted it. I have by far no clue how I can make it the way Cura / Prusa Slicer do it. But at least I am happy I got somehow a support.)

Still internal functions may change in one or the other way, also the more internal API (such as if you want to replace one specific part of GoSlice or add additional custom modifiers or renderers) may not be that stable.

But as you just call the slicer as it is, you touch only the passed options (either through cli or the options struct) and both are basically kept in sync. If a new option is added it's also added to the CLI, if it changes somehow the behavior of one option, it will also change if you pass the option through the CLI.
So it doesn't matter if you use GoSlice as lib or as CLI binary.

As I use version-tags (like it's anyway needed for Go modules) you can safely just pin to one specific GoSlice version in the go.mod file. That way you do not have to worry about a changing api even if I published a new version because SlicerA still can use the older version. So it shouldn't be a problem for your second point. Because every time you build you will get exactly the version you pinned in the go.mod file.

Basically the only API you need (if you do not want to replace internal modules) is this:

options := DefaultOptions()
p := goslice.NewGoSlice(options)
err := p.Process()
if err != nil {
  fmt.Println("error while processing file:", err)
  os.Exit(2)
}

This won't change in any breaking way.

Where options is the option struct, where you can set the slicing options and input / output file. Basically everything in that struct is just exposed to the cli directly. So it doesn't really matter if you pass values by cli or by the options struct.

As I know that at least you use GoSlice, I can promise you: If I change anything in that options doing a breaking change, I will just deprecate old values and only remove them in a next major version. I try to do the same for the CLI.

The only thing I cannot promise is that nothing changes internally but also then it doesn't matter if you call it as lib or as cli. Just pin the version and you will get what you think you get until you explicitly do an update of the pinned version.

After all I think it's a much cleaner, more stable and simpler way to call it as lib and you can still use the specific version you want. For example setting the values through the CLI is much more error-prone than by setting the values directly to the struct as you then have complete typings.

That's my thought about it :-)