Publish Scoop package

[kotx]

Scoop compared to Chocolatey- basically, it installs portably and has simpler configuration. Creating a package for this can be done fairly easily using GitHub Releases and autoupdates, I would be willing to PR this into the main Scoop repo if you wish.

[slonopotamus]

Hi! I personally never used Scoop. It looks like Stevedore would have to go into non-portable.

Stevedore uses GitHub Actions for CI and releases, so if we could just push a new release to Scoop from there, it would be cool.

I'm not sure I properly understood that autoupdater thing. It polls upstreams for new releases and submits a PR to Scoop when finds one? That should also work.

[kotx]

It seems that MSIs can be extracted automatically if the filename contains .msi- this might work, unless there is another non-portable aspect of Stevedore. For example, the 7zip manifest seems to use an MSI file and extract it to the ~/scoop/ directory.

How autoupdater works is that you can specify for Scoop to query GitHub Releases for a new version, and then update the manifest to the new version. For example, this is the manifest for @railway/cli:

{
    "version": "0.3.1",
    "description": "The command line interface for Railway. Use it to connect your code to Railways infrastructure.",
    "homepage": "https://github.com/railwayapp/cli",
    "license": "MIT",
    "architecture": {
        "64bit": {
            "url": "https://github.com/railwayapp/cli/releases/download/v0.3.1/railway_0.3.1_windows_amd64.tar.gz",
            "hash": "45110d5753d49ffb2a4ca074d4696c9092b441f4e9deed5475e67c6fedbeb30e"
        },
        "32bit": {
            "url": "https://github.com/railwayapp/cli/releases/download/v0.3.1/railway_0.3.1_windows_386.tar.gz",
            "hash": "a64e28cdade44da3eed02e58c1152e8101ee6fc5d4ef55605b9075082f3413ee"
        }
    },
    "bin": "railway.exe",
    "checkver": "github",
    "autoupdate": {
        "architecture": {
            "64bit": {
                "url": "https://github.com/railwayapp/cli/releases/download/v$version/railway_$version_windows_amd64.tar.gz"
            },
            "32bit": {
                "url": "https://github.com/railwayapp/cli/releases/download/v$version/railway_$version_windows_386.tar.gz"
            }
        },
        "hash": {
            "url": "$baseurl/railway_$version_checksums.txt"
        }
    }
}

Autoupdater is run on the bucket's side IIRC, so you won't have to do anything in your Actions workflows, you just need to push a new release to GitHub Releases.

[slonopotamus]

unless there is another non-portable aspect of Stevedore

1. Stevedore installs Windows service
2. Stevedore enables Windows optional features (containers & Hyper-V)

Both options require elevated privileges, and service is obviously non-portable.

[kotx]

Both options require elevated privileges, and service is obviously non-portable.

That makes sense. Is it alright if I open a PR to the nonportable bucket for adding Stevedore? I can put in a PR for adding it to the README as well.

[slonopotamus]

Is it alright if I open a PR to the nonportable bucket for adding Stevedore?

Sure!

[kotx]

I created a PR at https://github.com/TheRandomLabs/scoop-nonportable/pull/296. I used the Wix installer/MSI as a reference hopefully I haven't missed anything that Stevedore does in the install process. Since I use dockerd --register-service, the display name of the service is Docker Engine rather than Stevedore, but the service name is still stevedored. LMK if this is a problem.

[isanych]

scoop docker package installing without admin privileges and print message after installation:

        To register Docker as a service, run `dockerd --register-service`
        Similarly, to unregister, run `dockerd --unregister-service`

stevedore can use similar approach

[slonopotamus]

If you want to go the manual route, you can just

1. Download ZIP from https://download.docker.com/win/static/stable/x86_64/
2. Unpack it
3. Run dockerd --register-service
4. Install Windows Containers/Hyper-V feature
5. Reboot

The main point of Stevedore is that it does everything that needs to be done in order to use containers.

[isanych]

I don't want to use manual route - I'm installing most of my stuff via package managers, preferable scoop, chocolatey is ok for usage in docker containers, but scoop is more convenient on desktop and currently there is disparity in docker packages in scoop and chocolatey

[slonopotamus]

I'm not sure I understand you. Docker already exists in Scoop. Stevedore installs exactly the same docker.exe and exactly the same dockerd.exe. But Stevedore does several more things (like, enabling required Windows features and registering service). If you want to do those things by hand, you can just scoop install docker.

[isanych]

There is difference in installed binaries. scoop docker package installs docker app (which is deprecated) and buildx (which does not work on windows - hopefully yet), stevedore installs compose - and who knows how these packages will deviate in future.

Currently everything is manageable - I only write different instructions for users installing docker via scoop and via chocolatey (and there are no good options in winget AFAIK). If it deviates from project goals it is fine, but it is nice to have an option to install modern package with package manger of your choice imho.

Portable installations are useful depends on use case, for example I can install docker from scoop in docker container and use it as client, but choco install stevedore is failing in docker (which is understandable if package tries to enable containers support).

[slonopotamus]

scoop docker package installs docker app (which is deprecated) and buildx (which does not work on windows - hopefully yet), stevedore installs compose - and who knows how these packages will deviate in future.

stevedore aims to be a superset of docker package. So it does install both docker app and buildx.

choco install stevedore is failing in docker

I think you can workaround that by specifying which features to install: https://github.com/slonopotamus/stevedore#command-line-install-options. By default, Stevedore attempts to install everything.

WRT installing Stevedore per-user - this might work, but very great care needs to be taken to avoid making installer UI confusing. Anyway, I think it is out of scope of current issue because it isn't Scoop-specific.

[kotx]

Since the nonportable bucket seems to be inactive, we can either wait for it to be transferred/forked into the ScoopInstaller org or we can make our own Scoop bucket.