This discussion thread has excellent timing, because I was otherwise about to
come here and start a thread on the topic.
I have been interested in the weeds of Raku's fully qualified compunit naming
convention for a long long time, since I first saw it in Larry's Apocalypse 12
https://raku.org/archive/doc/design/apo/A12.html section on "Versioning".
My interest is not only for the Raku ecosystem itself but also its
generalization into programming languages or code repositories in the abstract.
For a key example, Raku's fully qualified compunit naming convention has an
analogy in the Java world for versioning of JARs in Maven Central et al, where
Raku's base-name plus "auth" plus "ver" correspond to Maven's "groupId" plus
"artifactId" plus version number. Or somewhat like "groupId", the typical Java
package naming convention that starts with a reversed internet domain name of
the creator.
Many years ago (before I knew about Maven etc) I adopted the Raku fully
qualified compunit naming convention for my own Raku-inspired projects including
Muldis Object Notation (MUON) and Muldis Data Language (MDL). Both my
format/language specifications and artifacts/compunits are versioned with the
base name plus authority plus version number triplicate.
The Raku docs seem to have evolved since then but the original mention of "auth"
in Apocalypse 12 highlighted internet domain names such as "http://www.some.com";
as an option, I quote (slightly paraphrased):
The syntax of a versioned class declaration looks like this:
class Dog-1.2.1-cpan:JRANDOM;
class Dog-1.2.1-http://www.some.com
class Dog-1.2.1-mailto:jran...@some.com;
class Dog-1.2.1-JRANDOM;
class Dog-1.2.1-http://www.some.com/~jrandom;
class dog-1.2.1-jran...@some.com;
For perhaps one of my most important contributions to this thread...
The way I see it, the best interpretation of "auth" is the more abstract
"authority" which is some kind of unique identifier for a real person or
organization that is releasing the artifact. This should be abstracted away as
much as possible from any actual repositories where the artifact is available.
If the general form of "auth" is basically "foo:bar" where "foo" defines a
delegating authority that controls a namespace and "bar" is the artifact
releasor's reserved name in that namespace, then it means "auth" is more a
lookup in an identity broker which is orthogonal to where the artifacts are
distributed.
In the modern day, I see that the internet domain name system is the closest
thing we have to a universal long term identity broker. A creator reserves
their name by registering and controlling the internet domain name.
While possibly not strictly required, I believe this is that the Maven "groupId"
and more generally the long-term practice of Java package names has done.
For my part, long ago, inspired by Apocalypse 12, I started using
"http://muldis.com"; as the authority/auth for my specs and compunits etc. See
https://github.com/muldis/Muldis_Object_Notation/blob/master/spec/Muldis_Object_Notation.md
for a specific example, both the VERSION at the top, as well as the VERSIONING
section at the bottom.
The way I see it, though an author or distributor may use different repositories
such as CPAN or Github to distribute things, all distributions by the same
person/org should use the same "auth", and different "auth" are for different
persons/orgs to distinguish themselves.
When you have a Raku compunit Foo that is declaring its own fully qualified
version, or is declaring its dependencies' fully qualified versions, they
shouldn't have to be more specific than saying, I am authority X, and I want
compunit Bar by authority Y. This is like pointing to a fingerprint identifier,
and that association should not break just because Bar is being distributed in
different places, and it shouldn't matter where the end user gets Bar from as
long as it is the same Bar.
So if an author decides that their id is "CPAN:jrandom" then they should keep
using "CPAN:jrandom" no matter where the artifacts are actually distributed.
This "CPAN:jrandom" isn't an instruction to get the module from CPAN, it is just
an instruction to get a module from anywhere the user is comfortable with per
their own policies that identifies itself as "CPAN:jrandom".
Independently from this, various repositories can have constraints that only
someone who has proven they own "CPAN:jrandom" on CPAN etc can upload things
with that auth, or at least while claiming that they are the same person.
So "auth" is really about portable identities, not repositories.
Now as for the original reason I was going to start this thread...
Per the Apocalypse 12 example, originally I was using "http://muldis.com";
qualified with "https://"; as a seeming standard way of being explicit that my
"auth" is an internet domain name and not say a CPAN id or whatever.
However, per developments in the last few years like "HTTPS Everywhere" and
such, with the web in general treating unencrypted HTTP like an obsolete
protocol people shouldn't be using anymore because security, it made me think
that I need to rethink my own "auth".
So something I was hoping to get input on is what is a recommended way to use an
internet domain name, say "muldis.com" or alternately its reversed "com.muldis"
form, as an "auth" while making it explicit that this is an internet domain
name, but without naming any protocols like "http" or "https" etc.
Is there some kind of best standard format for indicating this, eg
"domain:muldis.com" but standard?
So what are thoughts on what I said?
-- Darren Duncan
On 2022-05-06 6:48 a.m., yary wrote:
But I'm understanding from this conversation is that people have different ideas
of what the auth field means.
1. It shows who is responsible for this code. It is independent of which home
the author chooses, where home is GitHub, gitlab, cpan, zef,p6c etc.
2. It shows who is responsible for this code, and its main home. Auth does not
change when stored on other homes.
3. It shows who's responsible for this code in this home. It changes depending
on which home it is being uploaded to.
So it helps to consider some cases and how we handle it.
1. Long time Perl contributor has a CPAN authority, and decides to migrate all
existing projects to github as a main home.
2. Long time perl contributor has a CPAN authority, no Git account (local
development). She decides to distribute new Raku projects in zef primarily,
mirrored in CPAN because she loves metacpan's API and interface.
3. New contributor has modules in GitHub account, is agnostic as to ecosystems.
Wants every ecosystem to reflect latest pushes to main branch in their git account.
How should the auth field work for these cases?
More cases welcome... (Welcome to the bikeshead? 🚲🏘️🔵💚💜😢)
On Mon, May 2, 2022, 3:23 PM Marcel Timmerman wrote:
Hi,
I was wondering about the 'auth' specification in the meta file or
on the class/module/package. I was used to specify it as
'github:MARTIMM' because I store the stuff on GitHub for all the
goodies it offers. Now I see//that fez wants to start with 'fez:'
and when I look at the raku.land site for a module of mine I see a
remark /'/The uploading author of cpan:MARTIMM does not match the
META author of github:MARTIMM.' because I upload it to CPAN nowadays
and have never specified somewhere that the auth has become
'cpan:MARTIMM'.
I feel that this is not useful (even correct) to pin someone to use
an auth specification with a defined prefix for some ecosystem one
is using. So changing to another ecosystem forces that person to
change the auth everywhere in its code and meta files to get rid of
any errors or warnings. Besides that, the change of the author on
the same code poses the question later on, if that code is forked
and changed by someone else or that it is still the same developer
working on it?
Regards,
Marcel
