Perl 6 - the future is here, just unevenly distributed

IRC log for #perl6-toolchain, 2017-05-09

| Channels | #perl6-toolchain index | Today | | Search | Google Search | Plain-Text | summary

All times shown according to UTC.

Time Nick Message
05:45 domidumont joined #perl6-toolchain
05:46 domidumont joined #perl6-toolchain
05:53 domidumont joined #perl6-toolchain
07:21 domidumont joined #perl6-toolchain
09:54 z8 joined #perl6-toolchain
17:20 * sjn throws a €0.02 coin into the "RFC Native Dependency Specs for META6.json" pool to see what happens. :)
17:36 domidumont joined #perl6-toolchain
17:54 * nine claims that's more than just 0.02
18:00 sjn opinions have been devalued by inflation :)
18:01 sjn well. "deflation"
18:02 sjn I could have just said "let's just treat the whole problem as a protocol design issue"
18:07 nine But you didn't. Instead you posted a very nice and useful TODO list.
18:08 * sjn wouldn't be surprised if most of that "TODO list" could be implemented as a grammar :)
18:14 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:27 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:29 nine ugexe: why optional?
18:29 nine Isn't the same true for plain dependencies?
18:30 ugexe optional as in *this* or *that*
18:30 ugexe "depends" : [ ["JSON::Slow", "JSON::Slower"] ]
18:31 ugexe 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"
18:32 sjn ugexe: are you thinking about "I depend on either this or that implementation", or "I depend on either this or that API"?
18:33 ugexe the `use` string. the author is responsible for making sure they are using differing apis correctly
18:36 ugexe 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
18:37 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
18:38 ugexe but im saying that functionality would tie into this build stuff
18:39 sjn yeah, I see what you mean
18:40 sjn how about a new dependency list named "alternatives" that lets you list alternatives to one or more of the deps listed in "depends"?
18:41 sjn "depends" : [ "JSON::Slow" ]
18:41 ugexe the above list-inside-list is noted to do that
18:41 sjn "alternative" : [ "JSON::Slow", "JSON::Slower" ]
18:41 ugexe [ "Foo", ["Bar", "Baz"] ]
18:42 ugexe because you cant easily alternative your alternative that way
18:42 ugexe also duplicating that data is more error prone (the string JSON::Slow must be synced)
18:43 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
18:44 ugexe i'm ok with breaking zef for a cleaning spec
18:44 ugexe cleaner rather
18:45 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
18:46 sjn yeah, I'm also a fan of not-too-deep structures
18:46 ugexe but *just* nested aray?
18:46 nine It's not self documenting at all
18:47 nine 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:48 nine 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:49 nine It's basically once per dist instead of one per function or even more.
18:50 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:52 nine It should be easy for the fellow sysadmin to genereate puppet config from our META data
18:53 sjn yeah, consumers of the META6.json file might be very simple
18:54 sjn (other consumers than zef, that is)
18:59 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 nine Oh the joy...
18:59 ugexe a lot of spec needs to change to be consistently verbose
19:03 sjn ugexe: doesn't "supersedes" and "superseded-by" help with what you want to do?
19:03 sjn https://design.perl6.org/S22.html#supersedes
19:03 ugexe no
19:04 sjn ok, the two modules are equally supported
19:04 ugexe they are supported as a single namespace
19:06 sjn ...in other words... ::Slow and ::Slower offer the same API?
19:06 * sjn is maybe a little confused now
19:07 ugexe maybe
19:08 sjn if you're talking about "supersedes", then that meaning is pretty straightforward. the one is a replacement for the other
19:09 ugexe first { try (require ::($_)) } <JSON::Slow JSON::Slower>; # if they use the same api is irrelevant to the meta data
19:16 sjn I'd probably take a step back and have another fresh look at what you're trying to do here
19:18 sjn 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 sjn especially if the alternatives are supposed to be equally viable
19:18 ugexe the alternatives do aliasing
19:18 sjn now, if one is "better" than the other
19:19 ugexe and involve CUR work
19:20 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
19:21 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
19:21 ugexe consider that meta data doesn't even get looked up when a module is loaded
19:21 sjn what's not implemented? the supersedes pair?
19:21 ugexe well the meta data from the meta6.json
19:22 ugexe 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
19:23 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>;
19:24 sjn what's the additional meaning?
19:24 ugexe but now you have forced the assumption that the api is the same
19:24 ugexe because you are installing a namespace that may not be expected
19:25 ugexe maybe they need the actual namespaces, not the alias
19:25 ugexe it cannot represent "this or that" only
19:25 ugexe only "this or that aliased as this"
19:27 sjn what you're talking about here seems rather convoluted
19:28 sjn 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:29 ugexe no. it is declaring that one of two dependencies needs to be available in $*REPOs to run a given distribution
19:30 ugexe their similarity is irrelevant
19:30 ugexe i do not want to declare any level of similarity
19:31 sjn btw, we're actually talking about the same thing, but from two different perspectives
19:32 sjn let's talk about a use case for what you just wrote
19:33 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;"
19:34 sjn s/quoting/../
19:34 sjn ok it's not that
19:35 sjn then what is it?
19:38 ribasushi joined #perl6-toolchain
19:38 ugexe what is what?
19:38 sjn you said "...it means is not the same as ..."
19:39 ugexe not the same as what i stated previously
19:39 ugexe "no. it is declaring that one of two dependencies needs to be available in $*REPOs to run a given distribution"
19:40 ugexe "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:41 sjn yes, you need to have a separate depends field
19:45 ugexe [ [Foo::Core, [Foo::Plugin, Any::Plugin] ]
19:46 ugexe this cannot be expressed using the supercedes-style declaration
19:46 ugexe at least not in a way that makes no sense
19:48 ugexe as it would requiring aliasing 1 *or more* namespaces as a single namespace
19:49 ugexe and yet I dont care about aliasing anything in this instance, just that one of these sets of modules is installed
19:50 sjn ...and that none of these sets are "better" than the other
19:50 ugexe policy, not spec
19:50 sjn you're saying "I don't care which one is available, just give me one of them"
19:51 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:52 sjn ok
19:52 sjn right
19:55 sjn 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 sjn but sure..
19:56 sjn let's say My::App's dependencies are [ My::Framework, [ Plugin::Demo1, Plugin::Demo2 ] ]
19:56 sjn then that would make sense
19:58 ugexe consider adapter/decorator pattern where the adapter might provide some common interface sure, but the adaptee/backends may be wildly different
20:06 * sjn would have assumed separate adapters, one for each adaptee/backend, where each adapter implements the same API
20:07 sjn but sure
20:09 sjn the adaptors might be DBD::mysql or DBD::Pg, and you just need any one of them to make DBI useful
20:10 ugexe thats one way. another popular way is runtime discovery.
20:11 sjn well, that's an implementation detail in the software that uses the adapters :)
20:12 ugexe ::PP / ::XS is another one
20:13 sjn anyhoo, I stand by my first suggestion. add another keyword for listing the alternatives, which might look like...
20:13 sjn "depends" : [ "DBD::Pg" ]
20:14 sjn "alternatives" : [ "DBD::Pg", "DBD::mysql" ]
20:14 ugexe that only works for the most basic use base
20:14 ugexe use case^
20:15 sjn what would a non-basic use case look like?
20:15 ugexe [ [Foo::Core, [Foo::Plugin, Any::Plugin] ]
20:18 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:19 sjn right?
20:20 ugexe no
20:20 ugexe it wants Foo::Core OR one of Foo::Plugin/Any::Plugin
20:21 ugexe its a list inside a list
20:22 sjn yeah, that can make things messy
20:24 sjn altermatives: [ Foo::Core, Foo::Plugin ]
20:24 sjn altermatives: [ Foo::Plugin, Any::Plugin ]
20:25 sjn meh
20:25 ugexe a recipe for out of sync data
20:25 sjn mm
20:25 [Coke] ugexe: if it wants A OR (B OR C) that's A OR B OR C and you'd not need a sublist.
20:26 nine depends: [{type: any, of: [Foo::Core, {type: all, of: [Foo::Plugin, Any::Plugin]}]}]
20:27 sjn [Coke]++ # point well made :)
20:28 [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 :)
20:29 * 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] :)
20:30 ugexe the dependency graphs will be messy
20:30 sjn how far should we bend backwards to help people make things like this work?
20:30 nine sjn: maybe depends: [{type: any, of: [Mojolicious, {type: all, of: [WWW::Mechanize, XML::XPath, ...]}]}]
20:30 ugexe i dunno, right now  there is only a few people implementing anything
20:32 ugexe 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
20:33 sjn KISS
20:33 nine ugexe: just JSON, not all of Javascript :)
20:33 ugexe right, more like openapi

| Channels | #perl6-toolchain index | Today | | Search | Google Search | Plain-Text | summary