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 <mt1...@gmail.com> wrote: > Hi Brad, > > Auth is for more than just the author. It is for author, authority, and > authentication. > > 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, ccworld1...@gmail.com, > 2291108...@qq.com', 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 > auth. > > 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.... > Regards, > Marcel > > > On Mon, May 2, 2022, 3:23 PM Marcel Timmerman <mt1...@gmail.com> 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 >> >> >
