add 0.38.7 winget manifest

[yak3d]

This would be the first winget manifest. We can update https://github.com/Mutagen-Modding/Spriggit/blob/dev/.github/workflows/ci-publish.yml to call:

wingetcreate update --urls https://github.com/Mutagen-Modding/Spriggit/releases/download/<NEW RELEASE VERSION>/Spriggit.zip --version <NEW RELEASE VERSION> MutagenModding.Spriggit

This will automatically make the new manifest and push the PR to https://github.com/microsoft/winget-pkgs for the new version. For this original version, we'll need to make the PR on winget-pkgs after this manifest is merged. I don't even think we even need the manifests in spriggit but it would be nice to keep them.

[Noggog]

Thanks for the PR!

Can you walk me through the steps needed the next time spriggit is updated? Just run that one command and good to go?

I don't even think we even need the manifests in spriggit but it would be nice to keep them.

Hmm, might complicate things. For ex, normally I work work work, make commits yada yada. Then randomly decide "time to push a version!" and create a github release that targets the latest commit tip and creates the executables. We can have that release CI run that wingetcreate update pretty easy. But it would be a bit hard(er?) to have it commit back the manifests to the repo... as the release has already been made and tagged a commit with the version stamp by that stage. Doesn't seem worth the complication too much, as the manifests aren't too interesting, and we could always refer to them in the official winget repo?

---

Who is the target audience for this winget? I see we've chosen the CLI to be installed. Would some users want the UI instead? Or are UIs not typically not done via winget? (I havent used it much myself)

[Noggog]

Let's maybe adjust the CI files in this PR too? We can merge this in, make the winget repo PR, and then push a new spriggit version here and see if it all updates as we expect?

[yak3d]

Thanks for the PR!

Can you walk me through the steps needed the next time spriggit is updated? Just run that one command and good to go?

I don't even think we even need the manifests in spriggit but it would be nice to keep them.

Hmm, might complicate things. For ex, normally I work work work, make commits yada yada. Then randomly decide "time to push a version!" and create a github release that targets the latest commit tip and creates the executables. We can have that release CI run that wingetcreate update pretty easy. But it would be a bit hard(er?) to have it commit back the manifests to the repo... as the release has already been made and tagged a commit with the version stamp by that stage. Doesn't seem worth the complication too much, as the manifests aren't too interesting, and we could always refer to them in the official winget repo?

Yeah to be honest I think we can skip committing them. If this PR is "approved" I can close it and create the PR into winget-pkgs and add you as a reviewer there instead.

Who is the target audience for this winget? I see we've chosen the CLI to be installed. Would some users want the UI instead? Or are UIs not typically not done via winget? (I havent used it much myself)

The audience I had in mind are the less technical modders (artists, writers, etc.) who use Spriggit with a team but wouldn't want to be burdened with putting a zip somewhere, setting PATH etc.

The UI is definitely possible to also add, I have to dig a little more. I have an uncommitted Wix Toolset project for an MSI that installs both the UI and CLI, sets PATH and adds a start menu shortcut. That MSI could be used to install straight from the MSI itself or used by winget to install the UI and make the start menu shortcut.

I also want to see if winget can create a start menu shortcut (I think it can), if so that would make the UI version even simpler since we wouldn't need to use the MSI.

[yak3d]

@Noggog i updated the ci-publish.yml to use https://github.com/marketplace/actions/winget-releaser. Here's what I'm thinking for a release plan:

1. A fork of https://github.com/microsoft/winget-pkgs is created in the Mutagen-Modding organization (required by winget-releaser to make the PR)
2. A token with the public_repo scope (required by winget-releaser to make the PR)
3. That token is then added as a secret to this repository at WINGET_TOKEN which is used by the workflow
4. We move the manifest files from this branch to the new Mutagen-Modding/winget-pkgs fork and add them there
5. We create a PR from Mutagen-Modding/winget-pks into the main winget-pkgs with the original manifests
6. Once that is approved/merged, we create a new Spriggit version and test the version update

[Noggog]

Yeah to be honest I think we can skip committing them

Sounds good

The UI is definitely possible to also add, I have to dig a little more

Cool! I think the only reason to maybe figure it out earlier rather than later is just so that the winget registry naming makes sense. is spriggit gonna get you the UI or the CLI? Do we do spriggit-ui and spriggit-cli?

A fork of https://github.com/microsoft/winget-pkgs is created in the Mutagen-Modding organization (required by winget-releaser to make the PR)

Done https://github.com/Mutagen-Modding/winget-pkgs
Let me know if it'd be easier to add you as a contributor to that fork at all!

A token with the public_repo scope (required by winget-releaser to make the PR)

Does this token need write access to make commits, i imagine?

[yak3d]

Cool! I think the only reason to maybe figure it out earlier rather than later is just so that the winget registry naming makes sense. is spriggit gonna get you the UI or the CLI? Do we do spriggit-ui and spriggit-cli?

I think the CLI is the only thing people would realistically launch from the command line so I don't think we need to alias it. The way 7zip does this and I guess we can do it too is the installer just installs everything, UI and CLI. I can commit the wix project I made for the installer and instead of winget using the .zip it can use the .msi that Wix produces.

If you want to alias it adding "-ui" or "-cli" to the end seems logical to me.

Let me know if it'd be easier to add you as a contributor to that fork at all!

As long as I can make PRs I should be good!

Does this token need write access to make commits, i imagine?

The docs just said public_repo 🤷

[yak3d]

@Noggog I've had some more thoughts on the UI vs. CLI. I think we should make separate packages for them. The installation of the UI is more complex because we need to make the start menu. In addition we also will have two separate .exe's and I don't think it will correctly be able to alias them as a result.

I will draft up a manifest for the UI but we first need to get #127 merged.

[Noggog]

Made a token with these settings

Added it as a WGET_TOKEN secret onto the spriggit repo

[Noggog]

Added the manifests to the mutagen fork of winget here

[yak3d]

Added the manifests to the mutagen fork of winget here

Sweet! Looks like I do need to be a collaborator to make the PR, if that's alright.

[Noggog]

Pushing out 0.38.8 that returns 1 if the CLI is given no args. Should help with the winget PR woes

[Noggog]

We'red we leave this off? Do you think we'd be able to redo the winget PR and get approved with the new status return code in 0.38.8 @yak3d ?

[yak3d]

We'red we leave this off? Do you think we'd be able to redo the winget PR and get approved with the new status return code in 0.38.8 @yak3d ?

It finally passed validation. Just awaiting moderator approval now.