description: A desktop app that runs a project’s own development commands —
build, test, lint, dev server — each streamed into its own terminal pane. The
commands come from a yv.yaml file committed to the user’s repository, so the
set of tools invoked is defined by the user, not by this snap.
upstream-relation: I am the upstream author; the snap recipe lives in the
application’s own repository.
supported-category: tools for configuring development workspaces/environments
reasoning: yv executes arbitrary host-installed developer tooling on the
user’s behalf — whatever their project’s yv.yaml specifies. Strict interfaces
grant only scoped file, socket and process access; none permits general
execution of host binaries. Detail below.
Why strict confinement does not cover this
home excludes dot-directories. That is where ~/.nvm, ~/.cargo, ~/.rustup,
~/.pyenv, ~/.rbenv, ~/.sdkman, ~/.gradle and ~/.local/share/mise live, so for a
large fraction of developers their node, cargo, python and java are invisible and
npm run dev fails immediately.
The executable set is unbounded and unknown at packaging time. A project may invoke
make, docker, kubectl, terraform, gradlew, bazel, a shell script committed to
the repo, or a tool that did not exist when this snap was built. It is read from the user’s
yv.yaml at runtime, so it cannot be enumerated in a plug list.
Working trees are not confined to $HOME. Users keep them on /opt, /srv, secondary
drives and network mounts, and yv scans a user-chosen directory for yv.yaml files.
The environment must be the user’s, unmodified. Each command runs in a PTY and the
value of the tool is that it behaves exactly as it would in the user’s own terminal. A
remapped $HOME or a snap-provided library path does not merely restrict the command, it
makes it produce different output than the same command run by hand.
What it does not need
No snapd-control. Updates are left entirely to snapd’s refresh.
No root, no sudo, no pkexec.
Import never executes. Importing a yv.yaml writes configuration only; commands run when
the user presses Run. There is no setup hook and no post-install script.
yv.yaml files arrive by git clone and are validated rather than trusted — bounded and
rejected on every axis rather than repaired.
Secrets live in a separate 0600 file that no export, share or committed config can carry.
It is plausible that there are technical reasons why this snap needs classic to work properly in all scenarios, but please note that classic confinement is a sensitive matter and it is reserved for mature, well-known applications published by mature, well-known entities. As of today, I believe that this snap doesn’t meet this criteria because of the following reasons:
The project seems to be very fresh, according to the upstream repository
The projects seems to have little/none community around according to upstream repository (contributors, issues, PRs, etc.)
I could not find evidences that the project has a strong enough user base currently
Thus, considering these factors, I think this snap should not get classic confinement as of now.
For now, you may try to distribute a strictly confined snap via the store or use an alternative channel (such as github releases) for a classic confined one. For a strictly confined snap:
home excludes dot-directories.
This can be achieved via personal-files. We could consider manual-connection for them
The executable set is unbounded and unknown at packaging time.
I believe this also falls under the unsupported reason access to arbitrary files on the system due to developer/user inertia (home and removable-media is almost always sufficient, though personal-files and system-files may be used under certain circumstances.
The environment must be the user’s, unmodified.
From my point of view, this is the most relevant reason, but I’m not sure that it alone will justify the use of classic even when/if the project become more mature and well-known. We will need to further understand what are the issues that users experience in real scenarios
Thanks for the detailed review, and for being clear about the reasoning — that’s a fair call and I accept it.
I’ll park the classic request for now, keep distributing the .deb, tarball and AppImage from GitHub releases, and come back once there’s real adoption behind the project.
