develooper Front page | perl.perl6.users | Postings from May 2022

Re: author specification

Thread Previous | Thread Next
Darren Duncan
May 11, 2022 21:02
Re: author specification
Message ID:
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 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 "" 
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-

     class Dog-1.2.1-JRANDOM;
     class Dog-1.2.1-;

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 

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 
"" as the authority/auth for my specs and compunits etc.  See 
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 "" 
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 "" 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 
"" 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 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

Thread Previous | Thread Next Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at | Group listing | About