[m-users.] On package managers for Mercury

[Peter Wang]

On Sun, 28 Jul 2019 21:34:43 -0500, Julian Fondren <jfondren at minimaltype.com> wrote:
> 
> I don't like JSON either. The point's made that XML is worse, but
> what about Mercury's own term reading? Just imagine all the
> validation code you don't have to write.

Just as an aside: the Mercury term syntax can change as the language
evolves, even if only rarely. This should be a consideration any time
you decide to base a format on the term syntax.

> ** Adding stuff to the 'extras' directory
> Packages: 34
> 
> Of all the "prior work" I think this is actually the best one that
> you can use right now. People that watch the Mercury github will
> see commits to it, and see when packages are added. It's easy to
> fork the Mercury repo and put your new extras in a branch that you
> can then submit back to the repo in a PR. People can see from the
> git log and from "main author" notices where the code came from.
> 
> I think this option just needs some encouragement, like a "How to
> submit your package to extras/" mini-doc on
> https://mercurylang.org/documentation/documentation.html

I think the "extras" model made more sense back in the day:

 1. setting up a public CVS repository and keeping it up was a pain
 2. sending/receiving contributions by email was the norm
 3. the language was evolving more quickly

But now:

 1. getting free, public code hosting is easy

 2. probably more people are familiar with the github PR model
    (and trying to apply patches broken by bad MUAs is no fun anyway)

 3. the language rarely changes in backwards incompatible ways now
    so keeping code up to date should be less important

The "extras" model also gates all changes through the few people with
write access to the 'mercury' repository. You don't want that.

Having all the code in a subdirectory of the fairly large 'mercury'
repository also deters use of the git submodules feature
for importing dependencies.

Peter