- revision: https://dashboard.snapcraft.io/snaps/dvc/revisions/11/
- source code: https://github.com/iterative/dvc/pull/2778
gitbut for binary data rather than text (similar to
git-lfs). A big feature is also
dvc runwhich supports executing external binaries (which needs
Another reason for
In that linked discussion on github it mentions not being able to access host binaries - snaps in general should be self-contained and should ship their own binaries like interpreters which they require to run - so if dvc used
stage-packages to stage
python from Ubuntu would that work?
Regarding general use-cases for classic confinement - could you please elaborate on some day-to-day specific use-cases for
dvc which do not work under strict confinement and hence why classic confinement is required?
Thanks for looking into this.
There are quite a few other
git-like tools which also require classic confinement.
git (amongst other things) under-the-hood (which as-is requires
classic confinement: see the
git-ubuntu snap), but also does
git-like things in and of its own regard.
This includes a core feature of allowing users to save and re-run any arbitrary command involving external binaries (not just
git config alias NAME '!ARBITRARY_BINARY', though, running external binaries is a commonly used core feature of
dvc. This includes
dvc run and
dvc repro. The former feature is important enough to be listed on the landing page (https://dvc.org/):
$ dvc add images $ dvc run -d images -o model.p cnn.py $ dvc remote add myrepo s3://mybucket $ dvc push
We really did try to use
classic (https://github.com/iterative/dvc/compare/537d51b5351926732566256369189ed7a63e4208..f6e92184e389f95ed39b109f40fbe41de1f3cf9f) but even if we could fix the other issues,
dvc run would not work.
dvc is OSS-approved Apache 2.0 licensed with full source code and automatic CI snap building online, so it’s also clear that it’s not abusing
Thank you for the feedback. Please note that git-ubuntu is a very old snap that predates our Process for reviewing classic confinement snaps. Since then we have various facilities for allowing applications to use git in various ways, specifically The personal-files interface which snaps like gitl and icdiff use effectively without classic confinement. It is for these reasons that we are asking questions to understand the best path forward.
dvc run command makes it clear that this snap requires classic to function, since it can specify any user-provided command that might do anything, and these commands would only function correctly with the host’s filesystem, not the snap’s runtime if it were strict. Looking at the upstream website, dvc basically falls into the existing classic category of “tools for local, non-root user driven configuration of/switching to development workspaces/environments”. Ie, all the context for the ML experiment is saved in git by the user, then checked out (or pulled down on another machine) by the user, and then the
dvc run command is invoked by the user.
The requirements are understood. @advocacy - can you perform the vetting?
@advocacy - can someone please perform the vetting?
I have reviewed this request and vetted the publisher, +1 from me.
This is now live - note I don’t seem able to trigger the automatic snap review from the store for the existing revisions, and so am not currently able to approve them - however, if you upload a new revision to the store this should pass the automated review and allow you to publish it automatically.