Chapel: Mason: mason publish --check

[oplambeck]

mason doctor command would run a series of tests on a mason package to test compatibility of with the mason registry.

Will test things that can be done without building mason packages. Toml meta data errors, smoke check of compatibility, and version formatting.

Will be separate command within mason, most likely be integrated into mason publish as well.

@ben-albrecht @Spartee

[Spartee]

Will our version of doctor check for things like broken symlinks and missing dependencies? Might be confusing to name it doctor if we are not.

For reference, here is the code for the brew doctor command. Just curious how ours will stack up given that our design is so similar to Cargo's.

[ben-albrecht]

I think it'd be helpful to create a table or list of checks we expect mason doctor to do in this issue. There is also a fair number of tasks that mason can and should do by default for the user without an explicit mason doctor call. We should try to distinguish those checks here I think.

[oplambeck]

Am I understanding correctly that mason doctor a higher level of checks than simply what it takes to build and run a mason package. It seems that a fair amount of the errors we listed in our brainstorming don't allow for a mason package to be be built at all, ie name mismatch and a syntax error within a toml. With that in mind I would appreciate your guys input on a list of errors that won't stop a package from being built but would stop integration to a registry.

-more than one main module in a mason package
-source field errors
-Field Data type (author array of strings)

These are are also things can be checked without building the dependencies/the package itself

[Spartee]

Package aspects Mason checks

• Syntax errors within the Mason.toml (partially)
• Package name
• Existence of required field for specific command (e.g. source for mason publish)
• Chapel version compatibility
• Package version formatting
• Chapel version formatting

Package aspects mason doctor could cover

• Dependency incompatibilities in child dependencies of system and spack packages
• Dependency existence (For mason, spack, and system packages, the build just fails)
• git checks (are repo/author/remotes configured)
• External package spec (check against spack spec)
• Main modules
• Mason version

for reference, here are all the checks of brew doctor link

Also, I think given the difference between the two commands we should be calling this command something else. Possible candidates are:

• mason mortar (Owens idea)
• mason check
• mason status

[ben-albrecht]

So it seems like brew doctor is more about checking potential pitfalls in a user's homebrew setup while mason doctor would be more geared towards ensuring the correctness of packages to be added to the mason-registry.

I could see value in a separate mason doctor command that does stuff similar to brew doctor, so I agree we should consider other names.

I like the names mason mortar (a prerequisite check to adding a "brick" to the mason-registry), and mason check (more self-documenting in what it's doing).

Another design consideration: Should this command support different registry targets than the default mason-registry? I would guess yes, unless there are checks that are mason-registry-specific.

[Spartee]

I think mason check implies more of the brew doctor type of check whereas mason mortar could grow into a really specific meaning for us. Let it be known that this would be one of our few deviations from Cargo.

Also @ben-albrecht maybe a --local flag?

[ben-albrecht]

I think mason check implies more of the brew doctor type of check whereas mason mortar could grow into a really specific meaning for us

True. I'm not opposed to mason mortar as this command, and adding mason doctor as a separate command later. I'm also not opposed to saving mason mortar for something else in the future.

Also @ben-albrecht maybe a --local flag?

I like the idea of having a mason doctor that does the typical user pitfall checks that brew doctor does, and having a flag enable the additional checks that are described in this issue. This has the benefit of reducing sub-command pollution.

However, I don't know if --local captures what these checks are doing accurately. The main use-case (beyond our CI testing) will be for users to check if the package they are developing is formatted correctly to publish to a registry. There may be another flag that capture this better, like --ready or --stage-brick.

Following that suggestion, what if all of these checks were just integrated into a flag for mason publish? e.g. mason publish --dry-run or mason publish --check would run this series of tests to confirm that your package is ready to publish, and we could also run this in the CI testing for the main mason-registry too.

I'd choose mason publish --check if we decided we didn't want to overload --dry-run for some reason, e.g. maybe these checks take a non-trivial amount of time to complete.

[oplambeck]

@ben-albrecht I was assuming that mason mortar/doctor/check would follow the same workflow that the expansion of mason publish, ie mason mortar --registry <path> where path can be a local or remote path to a personal registry and the absence of a --registry flag would us the official mason registry in relation to the checks.

[ben-albrecht]

@ben-albrecht I was assuming that mason mortar/doctor/check would follow the same workflow that the expansion of mason publish, ie mason mortar --registry where path can be a local or remote path to a personal registry and the absence of a --registry flag would us the official mason registry in relation to the checks.

Agreed. This parallel with mason publish makes me favor adding this functionality to mason publish --<some-flag> even more. What do others think about this?

[oplambeck]

Makes sense to me. I like the idea of mason publish --check as a larger scale and depth --dry-run to ensure that the package is ready to publish. How would this play into trying to --check against a registry that is not the official mason-registry? Seems like to me that a --check flags would support the idea of a positional argument of a path to a registry instead of a --registry flag as referenced in https://github.com/chapel-lang/chapel/issues/13365

[Spartee]

@ben-albrecht @oplambeck Agreed --check works for me. I also like that it implies that what you are checking is that your package is ready to publish.