-
name:
scider -
description: Scider is a desktop IDE/code editor for software development. It provides project and workspace editing, an integrated terminal, source-control integration, language tooling, build/run/debug workflows, and support for development tools and extensions that operate within the user’s local development environment.
-
snapcraft: PRIVATE
-
upstream: PRIVATE
-
upstream-relation: I am part of the team that develops and publishes Scider and am authorized to publish the official Scider snap.
-
supported-category: IDEs
-
reasoning: Scider requires classic confinement because, as a general-purpose IDE, it needs to interact directly with the developer’s host development environment in ways that cannot be adequately provided through the existing strict-confinement interfaces.
In particular:
-
Executing user-selected and project-specific development tools
Scider needs to execute development tools installed on the host, as selected by the user or configured by their project. These can include Git, shells, compilers, interpreters, language runtimes, debuggers, build systems, package managers, language servers, and project-local executables.
The exact commands and binaries cannot be known at snap build time because they depend on the user’s development environment and individual project configuration.
-
Integrated terminal and shell execution
Scider includes an integrated terminal and needs to launch the user’s shell and execute arbitrary commands entered by the user.
The terminal needs to operate as part of the user’s normal development environment, including access to host-installed development tools, PATH configuration, environment variables, SDKs, runtimes, and project-specific tooling.
-
Build, run, task, and debug workflows
IDE workflows can execute user- or project-defined commands. For example, a workspace may configure its own build command, test runner, compiler, debugger, script, package manager, or executable.
Scider therefore cannot enumerate a fixed set of commands or host binaries that it will need to execute ahead of time.
-
Host development environments and toolchains
Developers may have SDKs, language runtimes, virtual environments, compilers, debuggers, and other toolchains installed in locations outside the snap runtime.
Scider needs to discover and invoke those existing host tools rather than forcing users to maintain a separate development environment exclusively inside the snap.
-
IDE extensions and language tooling
IDE extensions and language tooling may need to invoke project-specific or user-configured tools and language servers. Which tools are required depends on the languages, frameworks, extensions, and projects being used by each developer.
Strict confinement interfaces can provide access to several individual desktop and filesystem capabilities, but they do not provide the general host execution environment required for a general-purpose IDE where commands, toolchains, shells, language runtimes, debuggers, and development tools are selected dynamically by the user and their projects.
Running arbitrary user-configurable commands and interacting with development tools on the host are fundamental parts of Scider’s functionality, rather than optional functionality that can be removed while preserving the purpose of the application.
-
I understand that strict confinement is generally preferred over classic.
I’ve tried the existing interfaces to make the snap work under strict confinement, but they are not sufficient for the requirements described above.