DRAFT: Generates verification file for Chocolatey

[leoafarias]

A verification file is now needed since this cli_pkg builds an embedded package with the software included inside the package.

Have successfully passed the approval Chocolatey approval process with the dynamically generated file in this PR.

[nex3]

Are you sure this is necessary? My understanding was that it was required when shipping binaries to Chocolatey, but cli_pkg doesn't ship binaries—it just generates an install script that compiles the binaries on the end user's system.

[leoafarias]

@nex3 this is the information I received from their moderators. I can try to get more info, so they can provide a technical explanation for this requirement.

[nex3]

That would be good—as far as I know we've been successfully releasing Sass without a verification file.

[leoafarias]

@nex3 yes I had done a successful submission also that is why it seemed like it changed.

I will try to get more info from them…

[leoafarias]

@nex3 I have some more info, seems they define this type of package as "embedding the binaries" as per this link https://docs.chocolatey.org/en-us/create/create-packages#including-the-software-installer-in-the-package

Also, my guess what happens with Sass has a "Trusted package" status, which means it gets approved after automated checks, and won't go through moderation anymore.

I have asked some follow-up questions and can update once I hear back from them.

[nex3]

It sounds like that section is talking about embedding binaries, where cli_pkg ships the package source (plus an install script that compiles that source). Maybe the verifiers want to check that the source code that exists in the package is correct?

[leoafarias]

@nex3 This is their "official" response. I don't think I will push further.

I would disagree that this is not an embedded package.
Embedded means that the package contains the actual software, instead of only including scripts that download and install the software.
It does not matter if the software is in source code form or binary form.

Therefore, a verification.txt is required.

It is used to help moderators (and users as well) determine that the software included inside the package is original and unmodified from the official download location.

If you think this merge is not needed, maybe there is a way to just bring in a verification file, even though you won't have the "dynamic" approach to it, maybe that is a workaround.

What do you think?

[nex3]

Okay, in that case it sounds like this is necessary even if we aren't embedding binaries. Can you also add a test that the file is being created correctly?

[leoafarias]

@nex3 I have done the test, but was not able to run it locally. Getting the same error as the CI, but seems it was happening even before adding the test.

[nex3]

It looks like the tests are failing because you're referring to githubRepo in chocolatey.dart (line 331), but you aren't setting it in the tests.

Rather than always using the GitHub repo, it might make more sense to add a chocolateyRepoUrl field that uses githubRepo if it's available and otherwise throws a more specific error.

[leoafarias]

Have an implementation chocolateyRepoUrl, but also have to build the release URL, for the verification which assumes that is on GitHub. Maybe later I can implement a verification file override or a template override.

Will check why some tests are failing soon.

[nex3]

Tests should be fixed by #81.

Have an implementation chocolateyRepoUrl, but also have to build the release URL, for the verification which assumes that is on GitHub. Maybe later I can implement a verification file override or a template override.

I don't know if it's worth allowing people to override the entire verification file, but I think having chocolateyRepoUrl and chocolateyReleaseUrl be customizable variables makes senes.

[nex3]

@leoafarias Are you planning on circling back to this?

[leoafarias]

@leoafarias Are you planning on circling back to this?

Yes, haven’t had much time this week.

[nex3]

Looks like a handful of tests are still failing.

Since you're adding new config variables, there are a few additional steps to go through:

• Write tests that verify that their default values are correct and that the overridden values are used in the verification file.
• Update the task documentation in doc to indicate that pkg-chocolatey depends on pkg.chocolateyRepoUrl and pkg.chocolateyReleaseUrl.

[nex3]

If the user hasn't set chocolateyRepoUrl, they may be confused by the fact that they get an error about GitHub even if they aren't using GitHub deployment at all. It's probably better to explicitly fail with a message that says "pkg.chocolateyRepoUrl or pkg.githubRepo must be set to deploy to Chocolatey." Same for chocolateyReleaseUrl.

[leoafarias]

@nex3 I have limited time, but I would love to finish this out over this weekend. Do you mind pointing me at some examples of these tests as I am still becoming familiar with the inner workings of the package?

[nex3]

The GitHub configuration tests are a pretty good place to look:

dart_cli_pkg/test/github_test.dart

Line 41 in bf2815a

group("repo name", () {