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

Powered by Cro and the Raku® Programming Language.

Please report any issues / comments / feature requests as an issue on App::Raku::Log.

Thank you!