|
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 December 2016. |
|||
| ugexe | nine: I'm trying to come up with a way to explain what a "Recomendation Engine + ContentStorage" and "CompUnit::Repository" are. I intend to make a point that they are both the same thing and could really be called a Distribution::Repository - both meant to resolve a distribution name - with the only (non interface) difference that a CompUnit::Repository may have the ability to precompile. Is this a | 00:37 | |
| fair statement in your opinion? | |||
| thus Distribution implementations act as the intermediary between any two "Distribution::Repository" | 00:38 | ||
| and installing a distribution from CURI#site to CURI#home is essentially the same as MetaCPAN to CURI#site | 00:39 | ||
|
02:20
tadzik joined
02:50
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 | ||
|
07:28
domidumont joined
07:33
domidumont joined
|
|||
| nine | ugexe: the way I see it a CompUnit::Repository is a place where we can load modules from. A ContentStorage is a place where we can install modules from and a Recommendation Engine is something that decides which of the candidates from the Content Storage we install. | 08:35 | |
|
09:25
domidumont joined
12:30
FROGGS joined
|
|||
| lizmat | ugexe: the idea was to split the functionality that CPAN offers into separate parts | 12:56 | |
| PAUSE is a dropbox for modules | |||
| CPAN provides a module list for when to install module Foo | |||
| PAUSE in this context is the content storage | |||
| CPAN in that context is the recommendation engine | 12:57 | ||
| some people would like to e.g. not be bothered by people taking modules hostage | |||
| like JSON::XS (if I'm not mistaken) | |||
| so, ideally, they would like to use a different recommendation engine, one that would supply CPanel::JSON::XS when asked for JSON::XS | 12:58 | ||
| in the current setup of PAUSE/CPAN, that's not possible | |||
| by providing a different recommendation engine, it would | |||
| hope that makes sense ? | |||
|
18:13
Cheery joined
18:32
stmuk joined
|
|||
| ugexe | nine: ah yes, I forgot loading. but this, too, seems optional. CUR::Panda does not load modules (in a sense), it just reorders some things so that a different CUR can try to load a module it just added - CUR::Panda could not act as a lone CUR. | 18:55 | |
| CUR::Tar on the other hand does load modules, but is just some boilerplate around Distribution::Common::Tar. The boilerplate is essentially just CURAP with CompUnit::Loader.load-source-file($file) replaced with CompUnit::Loader.load-source($bytes). | |||
| This boilerplate can be reused around pretty much any Distribution implementation, because we can now do `$dist.content($path).slurp-rest(:bin)`. In this context a CUR is acting only as a mapping from `path-spec#foo` to Some::Distribution.new(...) | |||
| lizmat: I think I have a good understanding of the distinction between content storage and recommendation engine. However I am not sure if CPAN counts as a recommendation engine. I consider it the half of the recommendation engine that provides the package list, and another half is still needed to create the recommendation from that list. | |||
| MetaCPAN is an example I think demonstrates the entirely self-contained 'recommendation engine' concept, but a two component example would be a module manager parsing a package list (such as CPAN or p6 ecosystem) to determine what to actually fetch. I think the missing link for the JSON::XS/CPanel::JSON::XS example is actually the NYI `emulates`. | |||
| nine: lizmat: With all of that said, I'll go back to the original question "what is the difference between 'ContentStorage/Recommendation Engine' and a CUR"? Consider the simularities of the following: CURI.resolve('HTTP::Request'), Recommender.search('HTTP::Request'). The only real difference between them is that CURI.resolve shoves the distribution into a CompUnit object, but both still | 18:56 | ||
| theoretically have to abide by `emulates`, `supersedes`, `HTTP::Request:auth<foo>:ver<42>`, etc. | |||
| A CUR is actually implementing a recommendation engine, and this can be seen by installing `HTTP::Server` followed by `HTTP::UserAgent` - in this case HTTP::UserAgent is broken because it does `use HTTP::Request`, which also happens to be provided by `HTTP::Server` (this is actually fixed in HTTP::UserAgent by explicitly declaring the :auth<...>), and it tries to use the version from `HTTP::Server`. | |||
| I mention a broken example because it demonstrates that a CUR is not an infallible source of truth, and that it really is only making a recommendation. | |||
| mst | lizmat: I wrote p3rl.org/JSON::MaybeXS to make that problem go away | 20:04 | |
| lizmat | ugexe: never thought about the similarities of a CUR and a recommendation engine, I would need to mull a bit over that | 20:49 | |
| mst: thanks, but the point is really that you shouldn't have to make changes to your code to get around this issue | 20:50 | ||
| mst | lizmat: I don't disagree; the 'authority' concept in perl6 is something I really like | ||
| lizmat | mst: and since all module loading should/will be completely lexical, there is no way in Perl6 to preload the module "in place" | 20:51 | |
| mst | lizmat: hence why I kinda threw a chair when I discovered lexical module imports were NYI | ||
| lizmat | yes, know the feeling: we're getting there :-) | ||
| just over a year ago, module management was the big elephant in the room | 20:52 | ||
| mst | I think the look on my face when nine told me was roughly "I'm not sure if I want to kill you all or burst into tears" | ||
| lizmat | we've gotten a lot further now :-) | ||
| mst | yes | ||
| the progress is deeply impressive | |||