Interfaces auto-connect for prusa-slicer snap

Hello there,

I’d like to request auto-connect on the following interfaces, for newly created prusa-slicer snap.

  • home. Reasoning is that, being a 3d printing slicing program, it takes mesh files (STLs, OBJs, etc.) and converts to G-CODE and/or image streams to be consumed on the printers. Both input files and/or output files can/should be stored somewhere, so user can handle, store or even modify them.

  • removable-media and mount-observe. Many (if not all) printers come with an SD card slot, since that helps prevent input code shortages (PC freezes, etc.), since stopping printing in the middle of a part is often a non-recoverable error and may lead to hours of wasted time, electricity and material (filament). PrusaSlicer allows the user to save G-CODE files directly to a plugged SD card, if there’s one and, as such, it must be able to detect and access the media.

Store entry:

Please let me know if you have any doubts.

Thanks!!

The home interface is already autoconnected on classic distro.

+1 to auto-connect mount-observe since it seems a reasonable request if the application is dealing with SD cards.

As for removable-media, the description for prusa-slicer says “takes 3D models (STL, OBJ, AMF) and converts them into G-code instructions for FFF printers or PNG layers for mSLA 3D printers” so this falls broadly into the “media viewers/editors” category. Not to mention, common practice for this application is saving the media to an SD card so it may be placed in the printer to avoid printing hiccups.

A cursory glance at https://www.prusa3d.com/prusaslicer/ shows this is “a mature, well-known application”.

What remains is vetting the publisher according to at least one these criteria:

  • the snap’s (vetted) publisher is a mature, well-known entity
  • the snap’s (vetted) publisher is the upstream of the software
  • if the snap is published by someone other than upstream, the publisher must be vetted and either be an established committer to the upstream or the wider snap ecosystem (eg, an established well-known contributor to the software itself, a member of the snapcrafters group, etc)the publisher must be vetted and either be an established committer to the upstream or the wider snap ecosystem (eg, an established well-known contributor to the software itself, a member of the snapcrafters group, etc)

@ivo.cavalcante states a disclaimer on https://snapcraft.io/prusa-slicer which reads “This is an unofficial package , under development. Please report any issues to , unless reproducible in upstream version - and, thus, not a packaging problem.

which does not meet either of the first 2 criteria. @advocacy - can someone vet @ivo.cavalcante using this criteria: “the publisher must be vetted and either be an established committer to the upstream or the wider snap ecosystem (eg, an established well-known contributor to the software itself, a member of the snapcrafters group, etc)”?

@advocacy - if @ivo.cavalcante doesn’t meet these criteria, perhaps other options are available, like @ivo.cavalcante joining snapcrafters, snapcrafters being a collaborator on prusa-slicer, the snap packaging upstreamed, upstream commenting that they trust @ivo.cavalcante with the packaging, or something else.

Thanks for returning. I must have misunderstood the docs, was under impression that home interface auto-connect should be explicitly requested. As such, please ignore it.

I intend to take the snap upstream, once it’s mature. Not sure if they’ll be interested, since they already provide an AppImage as part of release process, but I’ll give it a shot anyway.

As for Snapcrafters, not sure how to proceed.

@reviewers - can others please vote?

@advocacy - ping, can someone please vet according to Interfaces auto-connect for prusa-slicer snap?

+1 from me for mount-observe as well for prusa-slicer.

@ivo.cavalcante Hi! Have you tried getting the snapcraft config merged upstream at all? I think if the configuration is merged upstream, or upstream are okay with you publishing it, that would help.

1 Like

Opened an issue few days ago. Waiting response. Ideally, they would have it merged and I’d hand them the name - and could help in maintaining the packaging. Let’s see how it goes.

1 Like

@ivo.cavalcante has there been any update on this?

Not really. Upstream didn’t merge snap yet - I’ve seen a similar request, for Flatpak, that’s waiting longer than I.

If I recall, there were two ways I could get this request approved: upstream adopting changes or becoming a Snapcrafter. I’ll give the second one a try, then.

Hey @ivo.cavalcante, I have checked and I see upstream did not merge your PR. So I assume you have not heard from them yet.

@advocacy, it is unclear what is happening with the vetting process. Can you please comment?

Hello @emitorino.

No, they’ve not merged and I got answer from them that they’ll not merge any other packaging format (Snap, Flatpak, etc.) other than the AppImage they already support, since they don’t have enough manpower to maintain it now.

I believe I won’t follow all steps needed in order to have the package “Snapcraft’ed” so, unfortunately, I think the request can be closed.

Thanks for your time.

Ok, thanks, removing this from our queue.