Move package modules into mason

[ben-albrecht]

Eventually, we'd like for existing package modules to be entirely converted to
mason packages, maintained outside of the chapel-lang repository, until they
meet the necessary requirements to be adopted into the standard library. The
requirements for being adopted into the standard library are being developed in
#10712.

Today, we have packages in 3 pools:

• mason
• modules/packages
• modules/standard

Long-term, we'd like to have packages in 2 pools:

• mason
• modules/standard

There may be some intermediate pool for packages in transition to becoming
standard modules.

Documentation

Beyond chpldoc-generated documentation, we would want to establish a standard
mechanism for hosting documentation of a given package.

Testing

Mason packages intended for standard library adoption or developed by Chapel team would be annotated with some property, e.g. "Cray-tested", and would be tested by the Chapel team on a regular basis.
Currently, we test the package modules during nightly testing as part of the
Chapel test suite. In the "package modules as mason packages" world, it seems
appealing to run this testing separate from our internal testing. This would
exercise the mechanism end-users utilize to test their packages.

This mechanism is dependent on #9730

[mppf]

If the goal is to be able to to migrate modules/packages over to mason, I think we should ignore the testing framework issue (testing can continue to use start_test for these for now) and allow nightly testing to use/test mason modules from chapel-lang/chapel.

[bradcray]

@mppf: I'm not clear on the details of what you're proposing. Would the idea be to have the start_test for such a package do the mason command to make it available for the test, e.g., via a precomp (or a new test system feature)?

A related question is how/where such mason packages (that we support) be documented.

[mppf]

Would the idea be to have the start_test for such a package do the mason command to make it available for the test, e.g., via a precomp (or a new test system feature)?

Something along those lines. The main idea is two parts:

1. We'd run tests for any mason package from chapel-lang/chapel
2. These would continue to use start_test (rather than the TODO testing framework)

I don't have a specific plan for how the details work out, though. The main idea here is to reduce the amount of things we'd need to do first before we can move things out of modules/packages and into mason (If only we had a testing strategy for general mason packages? But where would we host it? .... If only we had a user-facing testing framework).

What you described above sounds reasonable as a start. Another potential strategy would be for the test setups to populate modules/packages based upon the mason packages we want to test.

[bradcray]

Got it. I'm fine with taking baby steps, I just don't have a vision for what the first baby step would be. I.e., what specific actions we would take to move a given module from $CHPL_HOME/modules/packages to mason without losing current test and documentation coverage. Not to say one couldn't come up with one, just that I haven't (and was hoping from your previous response that you had).