Fire is step THREE! | github.com/perl6/toolchain-bikeshed | Channel logs: irclog.perlgeek.de/perl6-toolchain/today | useful prior art: metacpan.org/pod/CPAN::Meta::Spec
Set by moderator on 7 February 2016.
02:48 ilbot3 joined
moderator Fire is step THREE! | github.com/perl6/toolchain-bikeshed | Channel logs: irclog.perlgeek.de/perl6-toolchain/today | useful prior art: metacpan.org/pod/CPAN::Meta::Spec
02:59 FROGGS_ joined 04:21 MadcapJake joined 04:24 MadcapJake joined 07:11 FROGGS joined 07:33 domidumont joined 07:38 domidumont joined 10:41 cognominal joined 12:35 sufrostico joined 12:43 sufrostico joined 14:10 leont joined 14:11 japhb joined
ugexe right. i hope we can find a way to do it soon though... the longer no course of action is decided the more modules will rely on auth's one-of-many-possible-values 15:09
we have an advantage right now in that no one really uses auth in their code yet
i like the concept of auth being 2 distinct parts though. it would allow one to request a module from a specific content storage (like :auth('cpan:*')) 15:14
lizmat authority and storage should not be mixed, feels wrong to me 15:15
storage could be a clone / slave / mirror 15:16
ugexe storage is supposed to be its original location
(in my concept of it)
it would not mean "download it from cpan" 15:17
so cpan might host something with auth: "github:ugexe" 15:19
the recomendation manager can then determine any mirrors, wherever they may point 15:20
the key here is no data has to change in the distribution. so the same dist on 2 different services does not require modifying the meta6.json file (aka changing its checksum) 15:21
lizmat ok, if that's your definition of storage :-)
ugexe: yes
ugexe cpan is a storage yes. the original storage
15:25 prammer joined
ugexe "Please note that this is not an authority, merely an indication of the location where the distribution for that owner was obtained" # this is what leads me to this thinking 15:26
maybe i misinterpret it 15:27
lizmat ugexe: that part of the spec was largely handwavy 15:29
ugexe it makes sense to me though. and it makes a URN easier 15:31
think about it from a "i have to type this on the command line to request it in the first place" way 15:32
15:33 japhb joined
ugexe email address and urls are nice too, as they are unique. author name not so much ("John Smith", not so unique) 15:43
lizmat the authors section was always intended as additional, non-authoritative information 15:45
ugexe yeah i know... s22 mentions `owner` as filling the role author serves currently 15:46
even if changes are decided on any cant be made until another release they still help with the metacpan effort (which is what got me to bring this up in the first place) 15:56
s/any cant/and cant/
16:25 sufrostico joined 16:38 hankache joined 16:45 leont joined 16:54 sufrostico joined 17:24 FROGGS joined 17:45 autarch joined 18:08 japhb joined
jdv79 i thought auth indicated the actual entity such that cpan:jdv is jdv in the pause db and github:jdv is github user jdv. 18:34
not necessarily related to storage though i get why its confusing that is seems to imply such 18:35
18:39 japhb joined 18:40 kmel joined
jdv79 for instance, i could just publish the same dist on github, cpan, and some other "content storage" with an auth of cpan:jdv regardless of "original storage", right? I'm not sure what original storage means really. 18:42
flussence
.oO( I've half a mind to just start putting an email address there )
18:49
ugexe that can make it a pita to request from cli 18:50
18:58 japhb joined 19:20 domidumont joined 19:40 cognominal joined 20:07 Kassandry joined
nine What's hard about email addresses on the cli? 20:10
20:15 hankache joined 20:23 perlpilot joined
ugexe not that it doesnt apply to other ids, but the allowable characters lend themselves more to needing to quote the string than most user identification 20:25
jdv79 if it was a URN we could allow the email scheme. but on the other hand i don't think we can use the cpan and github scheme officially, right? 20:29
oh i meant URI. ugexe: why are you talking about URNs? 20:31
ugexe because cpan:JDV:Foo-Bar:1.0 is a URN, not a URI
it could be interpretted as one, but i mean this distribution could be downloaded from various locations 20:32
jdv79 a URN isa URI though:) 20:33
URN feels very 1999
but sure
20:34 prammer joined
jdv79 also, iirc, a urn is indicated by a urn scheme so its more like urn:cpan:JDV:Foo-Bar:1.0 20:38
ugexe sure, but i think we can forgo the urn:
my only point here is that it points at a resource without implying how to get it (urn) 20:43
so i guess i mean url instead of uri before
jdv79 i wonder why there isn't an email URN ns. it seems emails are only officially used an an URI via the mailto scheme which is kinda lame. 20:46
then again i'm not sure this level of formalism is worth the effort at this point. 20:47
20:54 prammer joined 20:57 prammer joined 21:02 prammer joined 21:19 prammer joined