Classic confinement request for slay-app

store-requests classic-confinement
1

Hello Snapcraft team,

I would like to request classic confinement for the slay-app snap.

  • name: slay-app
  • description: Slay is a smart launcher for developer tools and local development workspaces. It helps users discover installed applications, register IDEs and development tools, open projects with selected tools, manage SSH/SFTP connections, and work with developer environments from a single desktop application.
  • website: https://slay-app.dev/
  • snapcraft: The upstream repository is private, but the relevant Electron Builder snap configuration is included below.
  • upstream: PRIVATE
  • upstream-relation: I am the upstream author and snap publisher.
  • supported-category: tools for local, non-root user driven configuration of/switching to development workspaces/environments

I understand that strict confinement is generally preferred over classic.

slay-app needs classic confinement because its core functionality is to integrate with the user’s existing host development environment, not only with files and binaries inside the snap sandbox.

Technical reasons:

  • The application discovers installed host applications by reading .desktop files from standard host locations such as /usr/share/applications, /usr/local/share/applications, $HOME/.local/share/applications, and /var/lib/snapd/desktop/applications.
  • It resolves executable paths from the host environment and validates user-selected binaries.
  • It reads host icon/theme locations such as /usr/share/icons, /usr/local/share/icons, $HOME/.local/share/icons, and /usr/share/pixmaps to show the real applications available on the system.
  • It launches arbitrary user-selected host programs and IDEs, including opening a selected project directory with a selected executable. This is the main purpose of the snap: launching and switching between local development workspaces/tools.
  • It opens user-selected local project folders in the system file manager using the host desktop environment.
  • It provides SSH/SFTP tooling for developers, including reading user-selected private key files and creating local non-root port forwards for SSH connections.

I have considered strict confinement and existing interfaces, but they are not sufficient for the main workflow. Interfaces such as home, removable-media, desktop, desktop-legacy, x11, wayland, and network can cover some individual operations, but they do not allow the snap to reliably discover and execute arbitrary user-selected host development tools from the host filesystem.

Packaging the tools inside the snap would not solve the issue, because the purpose of Slay is specifically to launch the user’s already installed IDEs, editors, terminals, browsers, and other development tools with the user’s existing project directories and host environment.

For this reason, I believe slay-app fits the supported classic confinement category for local, non-root user driven configuration of and switching between development workspaces/environments.

Relevant snap configuration:

snap:
  base: core22
  confinement: classic
  grade: stable
  summary: Smart launcher for devtools
  title: slay
  artifactName: slay-app_${version}_${arch}.${ext}
2

Note that the snap-requests category is used for endusers to request new snaps from potential packagers so the packagers have a list to pick from.

For requests about interfaces, classic confinement and similar things please use the store-requests category and the respective sub-category for the specific request …

3

Thank you for the clarification. I created the topic in the wrong category by mistake.

Could you please move this topic to the store-requests category and the appropriate classic confinement sub-category/tag?

Thanks!

4

Hello @Gafchik!

I think the slay-app snap is a good candidate for classic confinement. Given its functionality, it falls under the officially supported category: Tools for local, non-root user-driven configuration of/switching to development workspaces/environments.

However, a key step before granting classic confinement is Publisher Vetting. Since the upstream repository is private, you will need to follow the Verified Accounts process described here.

What do other @reviewers think? Once this is completed, we can proceed with your request!