Snap

[casperdcl]

• remove stage: check # TODO: remove before merge from .travis.yml
• add snapcraft.yml
• add deploy.provider: snap in .travis.yml
  • postpone to after store approval. use GitHub releases in the meantime
• ensure version info PKG = "snap"
• ensure basic build
• ensure advanced build (all optional features & dependencies excluding tests)
• port over completion (https://github.com/iterative/dvc/blob/master/scripts/completion)
• remove "update/newer version available" message as snaps auto-update themselves
• add icon
• fix travis gssapi build
• minimise build (maybe don't use python plugin?)
• test connectivity and features
  • get classic approval
    • https://forum.snapcraft.io/t/classic-confinement-request-for-dvc/14124
    • rely on user-installed git (easy)
  • alternatively (for now) try with strict (hard)
    • use own internal version of git (dvc.git)
    • plugs
      • home
      • mount-observe
      • network-control
      • removable-media
      • system-files
• add SNAP_TOKEN to travis env var config
• release on snap store (edge channel)
• decide whether travis should auto-release to stable rather than just edge
  • decide on multiple release channels, e.g.:
    • on: tags -> stable or <tag>/stable or both (snap install dvc --classic)
    • branch: master -> edge (snap install dvc --classic --edge)
    • branch: <other> -> edge/<other>
• update readme with installation instructions
  • decide on badge
• fixes Snapcraft #2771
• basic dev ref: https://docs.travis-ci.com/user/deployment/snaps/

though personally I prefer

which I may have possibly contributed as a badge simple-icons/simple-icons#1215 😛

Before final approval, though, you can still test (after installing snap) by downloading from https://dashboard.snapcraft.io/snaps/dvc/revisions/6/download and doing snap install --dangerous --classic <filename.snap>

$ snap install --dangerous --classic <filename.snap>
$ dvc version
DVC version: 0.68.1+47e1b4
Python version: 3.6.8
Platform: Linux-4.15.0-58-generic-x86_64-with-Ubuntu-16.04-xenial
Binary: False
Package: snap
Cache: reflink - False, hardlink - True, symlink - True

[casperdcl]

And it's 2:15am... I should probably stop working on this for now.

[efiop]

@casperdcl Get some sleep from the... Nap Store... * sorry * 🙂

[efiop]

@casperdcl https://snapcraft.io/dvc Looks great! 🔥

[casperdcl]

fyi

• logo: modified https://github.com/iterative/dvc.org/blob/master/static/img/logo.png with extra transparent padding to make it 72x72 (1:1) as required by the snap store
• banner: modified https://github.com/iterative/dvc.org/blob/master/static/img/logo-github-readme.png by cropping and hacky extruding to make it 1080x360 (3:1) as required by the snap store
• video: linked to https://www.youtube.com/watch?v=4h6I9_xeYA4

[casperdcl]

also I need a list of your ubuntu one email addresses (you should sign up for a dev account via https://dashboard.snapcraft.io/) so I can add admin access to the snap for your accounts.

[efiop]

@casperdcl I actually have an ubuntu one account, tied to my gmail email (see my profile).

[efiop]

@casperdcl Do I understand correctly, that this can automatically deploy to snap on every merged PR (for edge) and also for every tag (for stable)? If so, that is amazing.

[casperdcl]

@efiop

The format for channels is [<track>/]<risk>[/<branch>]

So yes, we could do all of:

• on: tags: <tag>/stable or latest/stable or both
• branch: master: latest/edge
• branch: <other>: latest/edge/<other>

The last one would make it pretty easy for people to test out feature-branches...

[efiop]

Sounds great! No need to worry about feature branches, as we don't have those :) At least for now. master(for edge) and tags(for stable) would be perfect for now. If I understand edge purpose correctly, of course 🙂

[efiop]

So no additional flags needed for now? I'm completely lost with that classic approval. Is this even going to work without that approval?

[casperdcl]

added some explicit commands which users would need to run to grant permission (classic would grant everything)

[casperdcl]

I haven't tested all functionality so there's likely a few permissions missing...

[casperdcl]

I just did all of https://dvc.org/doc/tutorials/versioning and only got stuck at the end with dvc run since with strict confinement there's no way to access host system binaries (including e.g. python). Not something we can fix without --classic...

[efiop]

Isn't there a way to explicitly tell snap to install with "classic" permissions even if it is dangerous?

[casperdcl]

the snap won't be auto-downloadable (snap install --dangerous --classic dvc won't work). Users would have to download the snap file from the pending approval section (might even need logging in?) or from github releases and then snap install --dangerous --classic <dvc_VER.snap>

[casperdcl]

Maybe the latter is the only feasible option for now.

[casperdcl]

argh I'm close to giving up. Debugged all the plugs, tried confinement: devmode, and they still don't allow it. 💢

In any case confinement: classic will definitely be required for all functionality to work.

@efiop I'd recommend removing installation instructions from the readme for now pending classic approval.

[efiop]

@casperdcl Who "they"? Don't see any reaction from snap guys on the forum.

[casperdcl]

The automatic review bot runs checks and it turns out that even when using strict or devmode the system-files permission (required for reading /etc/hosts, /etc/host.conf, /etc/resolv.conf) still requires approval. And of course dvc run wouldn't work without classic. Nor do repos in certain types of external filesystem mounts.

[efiop]

@casperdcl Looks good, just one more comment about README ^ .

[casperdcl]

@efiop done I think

[shcheklein]

@casperdcl should we review and update our docs for linux? or are we waiting for an official approval?

[casperdcl]

Updated the readme in this PR but waiting for approval (#2760 (comment)) before going further I think

[shcheklein]

@casperdcl got it! Snap looks cool 😎 thanks for the effort ... when it's done may be it will be enough to get rid of pyinstaller indeed.

[casperdcl]

Hah I'm not sure that'll die any time soon. In the words of Joshua Bloch, "APIs are forever," and I think installation methods fall under the same umbrella, unfortunately.

[shcheklein]

:)

@casperdcl you are breaking my last hope :(

[casperdcl]

Hey, maaaybe in a year I'll consider dropping support for py2.6 in the packages I maintain. It's not hopeless; just hopeslow.