Chapel: Streamline creating local registries in Mason

[ankingcodes]

From #15076
Currently, to use a library project, which are not intended for distribution(not available on mason registry), we require :
(1) create a local registry
(2) add that github repo to their local registry as a package
(3) include that local registry in their MASON_REGISTRY env

This issue aims to streamline the process, so that it requires a minimal number of commands from an user.

[ben-albrecht]

I think a good first step to this would be to document the _exact_ commands a user needs to run in order to complete steps 1-3. From there, we can identify steps that can be combined into existing or new mason commands.

[ankingcodes]

@ben-albrecht
The set of commands are as follows:

1. Create a local registry

mkdir /path/to/local/registry

1. Add github repo to local registry. Suppose we have a repo called newProject

cd newProject
mason publish <path-to-local-registry>

1. Include that local registry in MASON_REGISTRY env

export MASON_REGISTRY="local-registry|/path/to/local/registry,mason-registry|https://github.com/chapel-lang/mason-registry"

[ankingcodes]

A new/existing command with a flag to use existing / create a local registry could be created to perform this. If user chooses to create a local registry, we perform 1 and 3 along with 2, else we perform only 2. What do you think ?

[ben-albrecht]

@ankingcodes - can you provide a copy/paste-able working example of the commands? I thought the registry had some additional constraints, like having a bricks directory and being a git repo.

[ben-albrecht]

A new/existing command with a flag to use existing / create a local registry could be created to perform this.

I agree. I think automating registry creation is definitely part of the solution.

One idea is for mason publish to take a flag to specify it is creating a new registry, e.g.

mason publish /my/local/registry --create-registry
# or
mason publish /my/local/registry -c

This tackles 1 & 2.

I don't know how we can automate 3, since no mason command can modify the user's environment. Perhaps the creation of a new registry can emit a message with the suggested command (for bash, at least), similar to how git push to a fork gives you the URL to open a PR against the upstream branch.

For example

> mason publish /my/local/registry -c
New registry created at /my/local/registry

Add this registry to the MASON_REGISTRY environment variable to include it in your search path:
    export MASON_REGISTRY=${MASON_REGISTRY},/my/local/registry}

Package published to /my/local/registry

[ankingcodes]

@ben-albrecht
Create local registry

mkdir local_reg
cd local_reg
mkdir Bricks DummyProject && touch 0.1.0.toml README.md
git init 
git add -A
git commit -m "first commit"
cd ..

Add local registry path to MASON_REGISTRY env

export MASON_REGISTRY="local-registry|local_reg,mason-registry|https://github.com/chapel-lang/mason-registry"

Create new mason project to add to local registry

mason new project
cd project
git add .
git commit -m "first commit"
mason publish ../local_reg

[ankingcodes]

@ben-albrecht I agree to your solution. Setting the env variable should be left to the user.

[ankingcodes]

Let's finalize on the flag. Should it be -c or --create-registry ?

[ben-albrecht]

I would be in favor of both, one short-hand for the other, similar to -h, --help or -V, --version.

I think it would be good practice to get input on this feature idea from another developer or 2 before pursuing this effort.

[ankingcodes]

Let's start a vote 😄

[ankingcodes]

Hit 👍 for -c

[ankingcodes]

Hit 👍 for --create-registry

[ankingcodes]

Hit 👍 for both -c and --create-registry

[ben-albrecht]

I think it would be good practice to get input on this feature idea from another developer or 2 before pursuing this effort.

Let's start a vote

I like your quick adoption to the voting system :)

I mostly meant for another developer to look at the overall proposal and say whether or not it sounds reasonable and/or point out any issues / other open design questions we may have missed.

[ankingcodes]

Haha ! Let's vote and give useful suggestions 👍

[ben-albrecht]

Pinging a random sample of people who have worked on or helped design mason features before:
@Spartee @krishnadey30 @benharsh @lydia-duncan

Looking for 1 or 2 opinions on the idea of a mason publish --create-registry flag whenever 1 or 2 of you gets a chance. Summarized as follows:

We are trying to streamline the process of making a local mason package available in a local registry for other local packages to use. The proposal is to add new flag(s) to mason publish to automate creation of a registry upon publishing. In the command output, print the (bash) command for adding that registry to the user's path, so they don't have to look up how to append to MASON_REGISTRY.

For example:

> mason publish /my/local/registry --create-registry
New registry created at /my/local/registry

Add this registry to the MASON_REGISTRY environment variable to include it in your search path:
    export MASON_REGISTRY=${MASON_REGISTRY},/my/local/registry}

Package published to /my/local/registry

# short-hand version of flag:
> mason publish /my/local/registry -c

[ben-albrecht]

What should mason publish <remote-registry> -c do?

I suspect it should produce an error message. Does anyone think otherwise?

[ankingcodes]

@ben-albrecht I agree with you to produce an error.

[ben-albrecht]

@ankingcodes - As a heads up, feature freeze is on Monday and core developers are busy wrapping up things for the 1.21 release. As a result, others probably won't have a chance to look at this design and we will not be able to merge an implementation until after the 1.21 code freeze period.

[ankingcodes]

@ben-albrecht How long do freeze periods last ?

[ben-albrecht]

The master branch will be unfrozen sometime between 3/16 and 3/26

[ankingcodes]

@ben-albrecht I am going to start working on this issue today. Summarising, this feature aims to introduce a new flag mason publish --create-registry | -c that streamlines the process of making a local mason package available in a local registry for other local packages to use.
Basically when we run mason publish <path to create reg> --create-registry from a mason project, the command should create the directories and initial files required for the registry, and publish our package in that registry.
What would happen for a case when we already have a registry at the given path, should we simply publish the mason project at the registry then ? Or should we show an error message for registry already exists.
Also, if you have any other case in mind, now would be good to discuss.

[ben-albrecht]

What would happen for a case when we already have a registry at the given path, should we simply publish the mason project at the registry then ? Or should we show an error message for registry already exists.

I think this should be an error, since the expected usage for publish to an existing registry is:

mason publish <path to registry>

Also, if you have any other case in mind, now would be good to discuss.

I wonder if it makes sense to support creating a registry without publishing a package to it necessarily. Seems useful, but I'm not sure it's useful enough to justify a new subcommand like mason registry <add|rm> (I can't think of an existing subcommand it would fall into).

[ankingcodes]

Seems useful, but I'm not sure it's useful enough to justify a new subcommand like mason registry (I can't think of an existing subcommand it would fall into).

@ben-albrecht That's definitely useful and is part of this issue. I think we don't require a separate command. Maybe mason publish --create-registry can be used for the first two steps mentioned here. Let's omit the last step and keep it to the user if they want to add their mason project as a package in the local registry

[ankingcodes]

The interface of the command would be

mason publish --create-registry | -c <path/for/registry/init/with/name/of/reg> 
# or 
mason publish <path/for/registry/init/with/name/of/reg> --create-registry | -c 

This would simply initialise the registry at given path with name as basename(path), and would also add this registry to MASON_REGISTRY env variable

[ben-albrecht]

and would also add this registry to MASON_REGISTRY env variable

We wouldn't be able to modify the user's environment, so we'd have to print out a message for them to do that themselves.

OK, so if I wanted to publish a package of mine, I could do:

# Create the registry
mason publish -c /my/registries/newRegistry
# Publish to the registry
mason publish /my/registryNewRegistry

Is that right?

[ankingcodes]

The interface of the command would be

mason publish --create-registry | -c <path/for/registry/init/with/name/of/reg> 
# or 
mason publish <path/for/registry/init/with/name/of/reg> --create-registry | -c 

This would simply initialise the registry at given path with name as basename(path), and would also print a message for MASON_REGISTRY env variable

[ben-albrecht]

Agreed. And then if they wanted to publish to that registry, they could follow-up with:

# Publish to the registry
mason publish path/for/registry/init/with/name/of/reg