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 8 May 2017.
05:45 domidumont joined 05:46 domidumont joined 05:53 domidumont joined 07:21 domidumont joined 09:54 z8 joined
sjn throws a €0.02 coin into the "RFC Native Dependency Specs for META6.json" pool to see what happens. :) 17:20
17:36 domidumont joined
nine claims that's more than just 0.02 17:54
sjn opinions have been devalued by inflation :) 18:00
well. "deflation" 18:01
I could have just said "let's just treat the whole problem as a protocol design issue" 18:02
nine But you didn't. Instead you posted a very nice and useful TODO list. 18:07
sjn wouldn't be surprised if most of that "TODO list" could be implemented as a grammar :) 18:08
nine Well we already keep our META data in JSON, so the low level details are already taken care of. I guess the hardest part of the work will be researching use cases to find out what the required or optional parts are. 18:14
ugexe to clarify the part i'm particularly interested in: I want to be able to be able to determine a working dependency graph before downloading any of the modules. so if there is an optional dependency for ["Foo", "Bar"] where one has a native dependency that is fulfilled then a build-free dependency graph/chain can be determined ahead of time 18:27
nine ugexe: why optional? 18:29
Isn't the same true for plain dependencies?
ugexe optional as in *this* or *that* 18:30
"depends" : [ ["JSON::Slow", "JSON::Slower"] ]
thats at least 2 different dependency graphs, because they each might have different dependencies 18:31
sjn optional, as in "either foo or bar will satisfy this dependency"
ugexe: are you thinking about "I depend on either this or that implementation", or "I depend on either this or that API"? 18:32
ugexe the `use` string. the author is responsible for making sure they are using differing apis correctly 18:33
so right now if i want to determine if i should use the JSON::Slow or JSON::Slower build graph I have to fetch everything for one and run their build/tests 18:36
sjn gets the feeling that a new keyword would be useful here
ugexe but if it can know just from the meta data it can be determined before build/testing everything 18:37
sjn anyhoo, that's a different can of worms
ugexe but im saying that functionality would tie into this build stuff 18:38
sjn yeah, I see what you mean 18:39
how about a new dependency list named "alternatives" that lets you list alternatives to one or more of the deps listed in "depends"? 18:40
"depends" : [ "JSON::Slow" ] 18:41
ugexe the above list-inside-list is noted to do that
sjn "alternative" : [ "JSON::Slow", "JSON::Slower" ]
ugexe [ "Foo", ["Bar", "Baz"] ]
because you cant easily alternative your alternative that way 18:42
also duplicating that data is more error prone (the string JSON::Slow must be synced)
sjn I'm thinking with a second keyword ("alternative"), older versions of zef don't get confused by the new addition 18:43
sjn assumes some stuff here, so I might be wrong
ugexe i'm ok with breaking zef for a cleaning spec 18:44
cleaner rather
nine One thing I learned from DBIx::Class is that nested array/hash structures make for a hard to use interface 18:45
ugexe its versioned now anyway, so can add a pinned version for older rakudos to ecosystem if needed
sjn yeah, I'm also a fan of not-too-deep structures 18:46
ugexe but *just* nested aray?
nine It's not self documenting at all
SQL is almost plain English and easy to get into. SQL::Abstract (DBIx::Class) is quick to type but you need to know what it means to be able to read it. 18:47
I tend to go with "if in doubt, err on the side of more verbosity". Especially when like with the dependency specification, most people won't spend any relevant amount of time writing it. 18:48
It's basically once per dist instead of one per function or even more. 18:49
sjn yeah. let's not forget that it's also important to make it easy to help the reader to understand what's going on 18:50
nine It should be easy for the fellow sysadmin to genereate puppet config from our META data 18:52
sjn yeah, consumers of the META6.json file might be very simple 18:53
(other consumers than zef, that is) 18:54
nine At works we have scripts run by puppet which do zypper -i -n in $(cat Makefile.PL | grep requires | perl -n -E "/requires '(.*?)'/; say qq{perl(\\$1)}") 18:59
Oh the joy...
ugexe a lot of spec needs to change to be consistently verbose
sjn ugexe: doesn't "supersedes" and "superseded-by" help with what you want to do? 19:03
design.perl6.org/S22.html#supersedes
ugexe no
sjn ok, the two modules are equally supported 19:04
ugexe they are supported as a single namespace
sjn ...in other words... ::Slow and ::Slower offer the same API? 19:06
sjn is maybe a little confused now
ugexe maybe 19:07
sjn if you're talking about "supersedes", then that meaning is pretty straightforward. the one is a replacement for the other 19:08
ugexe first { try (require ::($_)) } <JSON::Slow JSON::Slower>; # if they use the same api is irrelevant to the meta data 19:09
sjn I'd probably take a step back and have another fresh look at what you're trying to do here 19:16
if your software can use different modules to do the same job ("use different implementations, that may or may not offer the same API"), then it kinda looks like you're overcomplicating things 19:18
especially if the alternatives are supposed to be equally viable
ugexe the alternatives do aliasing
sjn now, if one is "better" than the other
ugexe and involve CUR work 19:19
sjn ...then a supersedes/superseded-by pair should handle the installation stuff, and I'd also assume that both implementations offer the same API 19:20
ugexe its not implemented period
sjn (either by aliasing or by just having the same method signatures) 19:21
ugexe and it will likely be no small feat to implement them
consider that meta data doesn't even get looked up when a module is loaded
sjn what's not implemented? the supersedes pair?
ugexe well the meta data from the meta6.json
supersedes, emulates, superseded-by, excludes (these are all in the same family essentially) 19:22
sjn yes, and what those do is offer help to figure out what's going to be installed
ugexe it cant just assume that, because it has additional meaning for CURs 19:23
sjn then -- later -- the program does something that looks like your { try (require ::($_)) } <JSON::Slow JSON::Slower>;
what's the additional meaning? 19:24
ugexe but now you have forced the assumption that the api is the same
because you are installing a namespace that may not be expected
maybe they need the actual namespaces, not the alias 19:25
it cannot represent "this or that" only
only "this or that aliased as this"
sjn what you're talking about here seems rather convoluted 19:27
it's a "I have to similar modules, and I want to use either one (whichever one is available), even if they really don't implement the same API." 19:28
ugexe no. it is declaring that one of two dependencies needs to be available in $*REPOs to run a given distribution 19:29
their similarity is irrelevant 19:30
i do not want to declare any level of similarity
sjn btw, we're actually talking about the same thing, but from two different perspectives 19:31
let's talk about a use case for what you just wrote 19:32
ugexe right, but what I just stated it means is not the same as declaring one of two dependencies, either of which will be available as "Some::Namespace" 19:33
sjn "use Foo as Bar || Bar;"
s/quoting/../ 19:34
ok it's not that
then what is it? 19:35
19:38 ribasushi joined
ugexe what is what? 19:38
sjn you said "...it means is not the same as ..."
ugexe not the same as what i stated previously 19:39
"no. it is declaring that one of two dependencies needs to be available in $*REPOs to run a given distribution"
"Please note that superseded-by has no meaning as a depends, so an installer should probably not automatically install any superseded-by compunits." # from s22 19:40
sjn yes, you need to have a separate depends field 19:41
ugexe [ [Foo::Core, [Foo::Plugin, Any::Plugin] ] 19:45
this cannot be expressed using the supercedes-style declaration 19:46
at least not in a way that makes no sense
as it would requiring aliasing 1 *or more* namespaces as a single namespace 19:48
and yet I dont care about aliasing anything in this instance, just that one of these sets of modules is installed 19:49
sjn ...and that none of these sets are "better" than the other 19:50
ugexe policy, not spec
sjn you're saying "I don't care which one is available, just give me one of them"
ugexe i'm not commenting on which one is chosen. I'm saying if one of the sets is installed that the dependencies for the distribution will be fulfilled 19:51
sjn ok 19:52
right
it still kinda seems weird... I'd expect that if one specifies a dependency and an alternative to it, they would at least "do the same thing"... 19:55
but sure..
let's say My::App's dependencies are [ My::Framework, [ Plugin::Demo1, Plugin::Demo2 ] ] 19:56
then that would make sense
ugexe consider adapter/decorator pattern where the adapter might provide some common interface sure, but the adaptee/backends may be wildly different 19:58
sjn would have assumed separate adapters, one for each adaptee/backend, where each adapter implements the same API 20:06
but sure 20:07
the adaptors might be DBD::mysql or DBD::Pg, and you just need any one of them to make DBI useful 20:09
ugexe thats one way. another popular way is runtime discovery. 20:10
sjn well, that's an implementation detail in the software that uses the adapters :) 20:11
ugexe ::PP / ::XS is another one 20:12
sjn anyhoo, I stand by my first suggestion. add another keyword for listing the alternatives, which might look like... 20:13
"depends" : [ "DBD::Pg" ]
"alternatives" : [ "DBD::Pg", "DBD::mysql" ] 20:14
ugexe that only works for the most basic use base
use case^
sjn what would a non-basic use case look like? 20:15
ugexe [ [Foo::Core, [Foo::Plugin, Any::Plugin] ]
sjn I don't see the difference. you always want Foo::Core, plus one of the plugins. that would make "Foo::Plugin" and "Any::Plugin" alternatives to eachother 20:18
right? 20:19
ugexe no 20:20
it wants Foo::Core OR one of Foo::Plugin/Any::Plugin
its a list inside a list 20:21
sjn yeah, that can make things messy 20:22
altermatives: [ Foo::Core, Foo::Plugin ] 20:24
altermatives: [ Foo::Plugin, Any::Plugin ]
meh 20:25
ugexe a recipe for out of sync data
sjn mm
[Coke] ugexe: if it wants A OR (B OR C) that's A OR B OR C and you'd not need a sublist.
nine depends: [{type: any, of: [Foo::Core, {type: all, of: [Foo::Plugin, Any::Plugin]}]}] 20:26
sjn [Coke]++ # point well made :) 20:27
[Coke] nine's A OR (B AND C) is harder, of course. 20:28
nine I don't like "type" there all that much. There must be a better word. But also it's kinda late :)
sjn gets the feeling that if someone is writing software that has such a messy dependency graph, then there might be some bad design decisions afoot 20:29
[Coke] :)
ugexe the dependency graphs will be messy 20:30
sjn how far should we bend backwards to help people make things like this work?
nine sjn: maybe depends: [{type: any, of: [Mojolicious, {type: all, of: [WWW::Mechanize, XML::XPath, ...]}]}]
ugexe i dunno, right now there is only a few people implementing anything
if you really want to declare it as a json spec, why not go all out with allOf, oneOf, etc? 20:32
sjn nine: horror! o_O
KISS 20:33
nine ugexe: just JSON, not all of Javascript :)
ugexe right, more like openapi

Powered by Cro and the Raku® Programming Language.

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

Thank you!