Front page | perl.perl6.users |
Postings from May 2022
Re: author specification
From: Brad Gilbert
May 3, 2022 18:43
Re: author specification
Message ID: CAD2L-T2Rt1kLSsi+JdYy4r+uJSwbmMjG9Fzdwkyb1GXJditXUg@mail.gmail.com
There could be a way for one of them to only act as a middle man. Basically
have fez defer to CPAN and just host a copy of it.
On Tue, May 3, 2022, 10:59 AM Marcel Timmerman <firstname.lastname@example.org> wrote:
> Hi Brad,
> Auth is for more than just the author. It is for author, authority, and
> There is no password or other cryptographic way, so authentication is not
> possible. Obviously, I might miss some insight here.
> In the documentation I read; ":auth generally takes the form hosting:ID,
> as in github:github-user or gitlab:gitlab-user". For me, hosting is e.g.
> on GitHub or Gitlab to store the software, and ecosystems are for spreading
> the word, i.e. telling that there is a software available somewhere, and
> this somewhere is not important. That is the work for zef to find out.
> And the word 'generally' means that it is just an example, it is in the
> end just a string.
> Furthermore, there is no mention in the docs of any use other than naming
> it in a useful way. No remarks of needing it to login into some ecosystem
> and no word about that separator, being a column, or split it up in more
> than two fields using an other character.
> Searching through some distributions I find 'zef:lizmat', 'github:MARTIMM',
> 'tonyo', 'cpan:WARRINGD', 'github:ccworld1000, email@example.com,
> firstname.lastname@example.org', showing that there is absolutely no clear way to use
> that field. For me, it means again that the auth field must be completely
> free and the same, independent of the ecosystem in use.
> CPAN can't authenticate github or fez modules, and vice versa. There is a
> reason the field is only the first four letters.
> The word 'github' is longer.
> That they are seen as different modules is an intended feature, not a bug.
> I didn't want to say that it was a bug, sorry for the confusion.
> I would like to know how you would want the system to handle a module from
> me. cpan:BGILLS github:b2gills and I intend to get b2gills on fez as well.
> (CPAN doesn't allow numbers, otherwise I would have it there to.)
> Do you want to write several meta files with different auth fields
> depending on the ecosystem you want to send it to? The only thing you can
> do without much work is sending a project e.g. to fez and another to cpan
> but I don't see the use of spreading your projects over several ecosystems.
> Also for a class you wrote, JSON::Class, what should I write (I took it to
> the extreme of course, 'use JSON::Class' would do)
> use JSON::Class:auth<cpan:BGILLS>;
> use JSON::Class:auth<github:b2gills>;
> use JSON::Class:auth<fez:b2gills>;
> All three are getting the same software, or not, when it is someone els-es
> What if someone else took a user name on github that matched one on CPAN
> or fez?
> That is the point I want to make. Keeping the auth field the same
> everywhere, independent of ecosystem, will show that the software is the
> same everywhere. If that someone has the same account name as someone else
> on cpan or fez it will show a difference in the auth field.
> So, I think there is a lot to ponder over....
> On Mon, May 2, 2022, 3:23 PM Marcel Timmerman <email@example.com> wrote:
>> 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
>> 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?