|
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 10 October 2016. |
|||
| tbrowder | okay, i see the whole thing is a bit more complicated than it seems at first glance. i will look but is the current ecosystem spec in one place or described in parts in perl6/ecosystem? | 00:21 | |
| ok, it seems to be in various parts of perl6/modules.perl6.org. any docs anywhere else you know of (probably lots encapsulated in zef and panda)? | 00:31 | ||
|
01: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 | ||
|
05:35
domidumont joined
05:39
domidumont joined
06:02
domidumont joined
08:36
sjn__ joined
08:49
JimmyZ joined
10:36
FROGGS joined
10:38
b2gills joined
11:31
stmuk_ joined
|
|||
| tbrowder | .tell ugexe See if my view of the ecosystem is correct in this gist: gist.github.com/tbrowder/6f36138f4...6ffc4bd7b5 | 12:37 | |
|
12:52
u65 joined
|
|||
| ugexe | tbrowder: you can't enforce cpan stuff in the current ecosystem | 14:20 | |
| how would you authenticate that | |||
| cpan and the current ecosystem should be viewed as two entirely separate entities | |||
| so cpan can define whatever meta fields they want to use as an interface, and the current ecosystem can (and currently does) define their own interface fields | 14:21 | ||
|
14:25
perlpilot joined
|
|||
| tbrowder | well, what would you do differently? it seems to me we could add whatever it takes to the meta file so transfer or upload to cpan could be automated. | 14:57 | |
| ugexe | if you are going to submit something to the ecosystem, why not just submit it to cpan | 14:58 | |
| tbrowder | well then why are we using modules.perl.org? in any event, i'm just trying to work on what we need to enhance the current system. i guess i don't understand the big picture and what the transition plan is. | 15:00 | |
| ugexe | because the system is meant to have multiple content storages | 15:01 | |
| if you have to run a dark pan its a lot easier to setup something like the ecosystem for instance | 15:02 | ||
| tbrowder | so what we have now is dark pan? if i just uploaded my modules to cpan i would see them on modules.perl6.org? | 15:05 | |
| ugexe | no | ||
|
15:06
FROGGS joined
|
|||
| tbrowder | then i don't understand why the objection to my observations for improvement on the existing system. | 15:06 | |
| ugexe | because you are requiring 1) oauth to be implemented somewhere so the ecosystem can auth against cpan 2) requiring cpan to add a specific interface to conform to perl6 isntead of perl6 conforming to the existing interface 3) assuming cpan and the current ecosystem will use the same meta6.json interface fields | 15:07 | |
| tbrowder | nothing at the moment is required. oauth implementation should be relatively easy to implement with p6 authors required to register with cpan. cpan shouldn't have to modify anything since the ecosystem could upload updates acting as each author during the transfer. | 15:12 | |
| maybe that's a naive vision, but it seems to be a good scheme to me. | 15:14 | ||
| ugexe | the current ecosystem serves no purpose in that scenario | 15:15 | |
| tbrowder | current module authors wouldn't have to change procedures much at all. | ||
| okay, i give up. i just don't understand the void between the current and dream systems. | 15:16 | ||
|
17:31
domidumont joined
|
|||