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 15 January 2016.
autarch I think I have a more or less working Test::Stream 04:44
and by more I mean it has events, a Test.pm6-alike sub exporter, and it has a context system for making sure that test events appear to come from the place where you call ok() rather than inside the ok() sub or elsewhere 04:45
and by less I mean no built-in IPC support and it could probably use more tests
and it has no docs yet 04:46
05:05 MadcapJake joined, yurivish joined 05:06 yurivish left 09:23 pnu joined
nine Sounds like great progress :) 09:39
11:09 jdv79 joined
jdv79 what did i miss? 11:10
11:11 stmuk_ joined, azawawi joined
azawawi hi 11:11
on windows, i want to depend on Alien::OpenCV::Windows to install the DLL . On unix, i need LibraryMake but not on windows 11:12
basically i need "depends" in META.info to be platform-specific
jdv79 i'm not aware of that being a thing. maybe there's a better place to make that distinction. 11:15
masak I redirected azawawi here because I wasn't aware of any solution. it sounds like a topic for this channel.
maybe start by asking: is there such a mechanism for CPAN? 11:16
jdv79 yeah, i can't recall ever seeing that done in that manner but i could be wrong. isn't there an escape hatch hook or something? 11:17
perpahs that would be done with "dynamic config" in p5 world 11:18
but i just came of hibernating for a couple weeks so probably best to not pay much attention to me:)
azawawi This is a real-life scenario. On unix, you can tell the user to 'sudo apt-get install libfoo-dev" and then use LibraryMake to build it 11:19
On windows, things are different and asking the user to get opencv zipped archive then extract and set an environment variables is a bit too much 11:20
s/variables/variable
jdv79 for now maybe panda's Build.pm feature can help you 11:23
i don't know much about it yet. sorry if that's not helpful. 11:24
azawawi no problem i was just thinking about the distribution footprint (+3.24MB uncompressed DLL) and windows compatibility. 11:26
i wanted a cleaner solution
jdv79 azawawi: doesn't seem that dirty to me. either bundle it or fetch it on the spot or require user action. 11:29
nine Yes, right now downloading the DLL on demand in a Build.pm sounds like the way to go. I don't know any other solution. But it's certainly a use case we're gonna want to consider.
jdv79 there may or may not be better ways later on for sure. maybe record this somewhere. do we have a file or a issues list or something yet? 11:30
azawawi jdv79: true, the problem is the LibraryMake dependency needs a working nmake which on windows is not the default
jdv79: you need to set environment variables for it to work 11:31
nine jdv79: there's github.com/perl6/toolchain-bikeshed 11:32
azawawi jdv79: and given you're going to download and not install it on windows, then LibraryMake is not needed on windows but was installed and maybe can fail during installation depending on environment
jdv79 ah. could you form this into some issue(s) on the repo nine just mentioned? 11:34
azawawi sure 11:35
jdv79 i'm still jetlagged and need some food. cool, thanks!
azawawi github.com/perl6/toolchain-bikeshed/issues/3 # done 11:43
masak++, jdv79++
11:45 azawawi left 13:51 FROGGS_ joined
mst autarch: what 15:47
autarch ?
mst autarch: the sub exporter part and ok() are *not* supposed to be in that part of the code
autarch: that's why the perl5 stuff ended up changing namespaces
Test2 is, correctly, just the streaming part
sadly perl5's Test::Stream released already with an exporter so we had to burn the namespace
please don't copy the same design error 15:48
autarch we can split it into multiple distros
but I needed to test that this stuff actually worked for the API that people want to use
mst ah, yes, you moved it to a random namespace to remind us that needed to be possible
sorry. every time you mention it without caveat I jump to "aaaaaaaa" since we've already had it go horribly wrong in perl5 space
autarch yeah, I don't think Test::Predicates is the final namespace this should be in
this is a prototype that exists purely so people can review the API design
mst I know that's not your fault but I hope you understand where my paranoia comes from 15:49
autarch I'm perfectly happy to rename all the modules, split it into several distros, etc.
mst right. that's what Test::Stream was supposed to be, then Exodist released it with stability guarantees while I wasn't looking and we ended up fucked
autarch and if anyone starts using it now they that's their problem - note that I haven't added this to the ecosystem yet either
mst yep
it's ok, had I finished my current coffee I'd probably've remembered we already covered this and you're already being sensible 15:50
I'd rather panic twice about a solved problem than not at all about an unsolved one though
autarch anyway, if you could review the API that'd be great - it's not a 100% port of the p5 stuff by any means, but I think it has all the things it needs 15:55
I think the next step is for me to build another more complex testing module on top of it, like Test::Class, which is why I started working on this in the first place
mst I would suggest you prod leont, since I think his review would be at least an order of magnitude more valuable than mine 15:56
autarch well, multiple reviewers is even better, but yes, I will ask him 15:57
mst oh, absolutely 16:05
autarch: repo URL?
autarch github.com/autarch/perl6-Test-Stream
there's no docs yet, because I don't want to invest a lot of time writing them before it's reviewed, which is a bit of a catch-22 I guess 16:06
mst well, lucky I usually read source before docs anyway then
16:41 domidumont joined 16:44 domidumont joined 18:34 leont joined 19:33 hankache joined
flussence writes a thing, lets it stew for a while: github.com/perl6/toolchain-bikeshed/issues/4 19:34
mst agrees except for an extra bit of paranoia 19:36
flussence aha, I was hoping there'd be some pushback there. 19:38
mst I agree we want to try and handle this. I agree META is where to put the info. I *really* don't want to end up with something that isn't fully battle tested in the spec 19:39
similarly to how rakudo tends to implement things a fair bit before they become 6.* spec material
flussence one vague end-goal I'm going for with this is to avoid the situatin Gentoo ended up with - package metadata with tons of flexibility... and can only be parsed correctly with bash 3 19:45
s/tin\\b/tion
mst right, turing complete dependency specifications can fuck right off 19:47
leont Yeah, let's please try to avoid that 19:50
mst rakudo currently totally supports them, per S22. I think the tooling is likely going to have to warn loudly when you do it but allow it anyway 19:55
flussence one thing I've noticed (and CPAN::Meta::Spec appears to be the same, fwiw) is we have ways to specify "I need everything in this list" and "I don't *need* anything in this list but it's here FYI", but not "I need at least one of the things in this list to work". That's easy enough to fix, I just haven't decided a good peg to hang it off of yet 19:59
mst yeah. the reason for that is that basically you could easily go from there to other binary combinations like "I need either X alone or both of Y and Z" 20:00
leont It's not a very common case, but it's useful every now and then
flussence I guess it's reasonable to just lump that in with optional dependencies for now, then 20:01
jdv79 i disagree with your proposal flussence
i just haven't delved and asked and thought enough to propose a real fix
except to say that parsing p6 in json is likely a bad idea
mst jdv79: what 20:02
jdv79 it should be splayed out into individual simple stringy things i think
mst we're talking about NOT parsing p6 in JSON here
flussence jdv79: some of these things are JSON keys, so it's kinda difficult to add structure to them... 20:03
mst well, I do admit that something like
{ "Foo::Bar" => { auth => "BOB, version => "1.3.*" } } 20:04
jdv79 part of the problem is trying to match up the dep meta with the use counterpart
mst would seem nicer to me as a syntax within the JSON
jdv79 that's got be a bit worried
*me 20:05
mst I'm not sure I understand, that problem is basically always going to be "you'll have to parse the .pm6 files for the use statement" no?
jdv79 well, iirc ver and auth and i guess api now can essentially be arbitrary at use time since they are spec'ed as just being a smartmatchable 20:06
mst but you said you disagreed with flussence's proposal, which is exactly about not doing that 20:07
I don't understand 20:08
ugexe isn't the 'one of these things in this list to work' solved by ['Wanted::First', 'Some::Backup']? (at least solved spec wise)? 20:09
jdv79 ugexe: but what if that doesn't pick the same thing that the use call does 20:10
if you have to parse the p6 code to determine deps that kinda sucks. i was hoping we could avoid that somehow. 20:11
similar to the insanity of requiring runtime deps to gen pod kinda 20:12
ugexe i dont think parsing the source will be a solution, especially with supercedes, superceded_by, etc
mst I'm really confused here
jdv79 ugexe: note that S22 is not set in stone. we could chuck it. 20:13
mst right, I want to chuck the turing complete parts of S22 as soon as possible
ugexe i dont see anything wrong with that part of the spec, or why it would require someone to parse the source to get dependencies
mst or at least declare them "you can use these in code, but don't expect the toolchain to even try"
yeah, I only mentioned parsing the source in terms of correlating the META6 info and where it came from
I mean, where it's being used 20:14
jdv79 for example, let's say we have something like this: use Dog:auth({ .substr(0,5) eq 'cpan:'}):ver({.match(/^1/)}); 20:16
how does the meta mirror that?
mst it doesn't
we declare that 'unsupported, fuck off'
jdv79 so to me that's a problem
welcome to p6 atm at leasy 20:17
ugexe ah, i do not like that either and mentioned this the other day as well
mst yes. that's a problem from S22, which we're going to have to apply cleansing fire to
jdv79 so either that closes down or meta tries to support it or we have an unbridged mismatch
also S11
as spec'd in 6.c...
mst I expect 'unbridged mismatch with loud warning' 20:18
jdv79 so that's a larry change
mst for the moment
I understand why the language offers it, but META ain't supporting it, because it's not going to work right
we -might- be able to bring limited stuff back later, but you'd start trending rapidly towards turing complete JSON
jdv79 yeah. i don't really understand why the lang has it. i just noticed the discrepency. 20:19
mst right. the point is, the discrepancy is both intentional and necessary 20:21
jdv79 but overall smells of not being thoroughly thought though
mst no, we've been thinking this through from the start
non-range or otherwise simple deps are just not going to be a thing any time soon 20:22
we've got enough other problems that are more pressing
jdv79 what start? i'm talking about S11 and S22 and related
mst the start of this channel, and the various discussions about producing a real world viable toolchain
the synopses' beautiful academic overcleverness notwithstanding ;) 20:23
jdv79 i'm saying they are not that beautiful except perhaps from a distance or just on the high points.
flussence I'm inclined to smack it with a YAGNI hammer here and wait until someone who actually needs a quantum hyperspace runtime-generated version number comes to complain about META being inadequate 20:24
jdv79 anyway, why can't we just take CPAN::Meta::Spec and adapt it minimally?
that was my first idea
and what i planned on exploring
mst 20:04 < mst> { "Foo::Bar" => { auth => "BOB, version => "1.3.*" } }
was meant to be gesturing at precisely that
jdv79 pretty much:)
mst but then we're using cpanmeta version declarations in META and ranges in code 20:25
so I wonder if we're better specifying range style version formatting for this
leont Well, versions would have to be one of the main adaptations
jdv79 well, with p6 adjustments
yeah
leont Otherwise, the prereqs format is superior IMO
sjn wonders if it would make sense to concoct a URN scheme for those module-author-versions 20:26
leont That said, to me it may make sense to separate prereqs from the other meta. They tend to be used in very different circumstances, and in p5 are often generated kind of differently.
jdv79 leont: in what ways? 20:27
are you talking about runtime/on the fly gen'd? 20:28
leont IN p5, the prereqs aren't really set until after configuration, in p6 we probably want to avoid that if we can
ugexe there is a speced urn, storage:AUTHOR:Module::Name:1.0 20:29
jdv79 i'm not sure what problem that solves but sure. 20:30
its also pretty easy to split it out like mst mentioned 20:31
ugexe sure because command lines love arguments with < ( quotes etc
jdv79 iirc p5 does static with dynamic mixin. perhaps that's almost exactly usable.
mst not entirely true 20:32
the META.json deps don't actual have to bear any relevance at all to the MYMETA.json deps
however 'MYMETA will, if anything, add deps' is what I'd consider well-behaved
(there's some fun fuckery in Moo's Makefile.PL to ensure we don't include optional deps in META even if we're building on a platform that needs them; not everybody goes to the effort) 20:33
jdv79 ok, but why can't we just do that more or less? 20:36
i also wonder if we have time to bang out a more real meta setup now or should we just fix it up a bit and stamp it and then work on a next ver with real sophistication 20:38
sjn what's a "more real meta setup"?
jdv79 oh. i mean something more resembling p5's level of support. 20:39
mst I think having one store for static-canonical meta, one for advisory prereqs, and one for final prereqs
rather than mashing the latter two into the former
might rather be an improvement
leont: is that what you were thinking about?
jdv79 what we have now is pretty rudimentary and doesn't even have solutions to some relatively basic things
leont mst: Sounds sensible. Even if we need some form of dynamic dependencies, that really should be more explicit than in CMS 20:41
jdv79 mst: curious why that's would be useful
oh, nm. yeah.
mst jdv79: "don't mash different things together" seems quite sufficient :) 20:42
jdv79 dyn deps will be necessary for at least plaform based choices right? it can also be the easy way to handle the use vs meta gap. 20:45
sjn btw, do we have a basic set of assumptions that we agree upon written down somewhere? (e.g. "no turing complete configuration" and "we'll use JSON as metafile format" etc.)
jdv79 im sure there's something that doesn't cover but seems better than trying to handle subsets of p6 syntax in static text formats. 20:46
sjn (do we care?) 20:47
jdv79 uh, there's S11 and S22 as suggestion atm. and i think whoever builds it first and gets it working and the community doesn't dislike terribly will stand. more of less
*or
to me json seems uncontroversial as well as your other point. 20:49
sjn uncontroversial != decided 20:50
but sure
there's also an issue of how far it's meaningful to go with the "no turing complete" requirement 20:51
jdv79 decided is a bit too strong a concept maybe.
:)
sjn do we handle post- and pre- install scripts? 20:52
flussence I think panda runs a "Build.pm", never used it myself though
and it's not really specced afaik, it's just something thrown in there because it was needed... 20:53
sjn how about about other build phases that may make sense, like post- and pre-build and a "filtering" phase where one might run .js file minifyers before build?
jdv79 if we do its a installer specific thing right now
non-spec yet
i don't believe so but panda may have changed since last i saw
flussence ufo used to run makefiles if they were present iirc, a long time ago 20:54
jdv79 panda run a "build phase" out of Build.pm i think
mst sjn: the point is 'turing incomplete dependency resolution' 20:55
that's the most important thing
jdv79 mst: well, statically.
mst jdv79: I was riffing off 'no turing complete', do you have a point or are you just nitpicking my language? :P 20:56
jdv79 and that versions in string form don't start with "v". might be a few other dumb things like that.
mst: well, you seem to be saying no non-static dep resolution. 20:57
ugexe zef used to support all those hooks
jdv79 maybe we should use that then
sjn mst: right, so no "dynamic dependencies", like leont mentioned? or is that a different thing in your mind?
ugexe problem is getting people to switch off Build.pm
leont ugexe: we need to first offer something better…
mst jdv79: I've no idea what you mean by 'non-static' in that case 20:58
jdv79 i don't think that's viable - "no dyn meta"
ugexe leont: i just said zef supported all the hooks sjn just mentioned
sjn ugexe: hey, cool
mst I'm not sure those hooks are a remotely good idea
autarch leont: please review github.com/autarch/perl6-Test-Stream when you get a chance - I have what I think is a working first draft of the API
ugexe sjn: it does not anymore, but it was implemented at one time. just everyone kept using Build.pm
mst ah
leont Hooks doesn't sound like a good solution 20:59
mst I misunderstood there. it's the Build.pm system that's heinous
then again, hooks might also be heinous
it's toolchain. about 99% of options are heinous
jdv79 then how do you handle things like win vs osx or a ver range or a more complicated "long name" match?
sjn think they are a *very* good idea to have, as long as they can be configured from a static file (
ugexe right, you could do your build stuff in whichever pre- hook made the most sense 21:00
mst jdv79: what
jdv79: I'm totally talking about version ranges being handled
I don't think I want to do os-specific stuff -yet-, that's the sort of thing where configure-time deps make sense
jdv79 i thought we were talking about config time. 21:01
are you talking about a subset of p6 range syntax or full on or something else then? 21:02
mst I was thinking re-casting the CPAN::Meta version system in terms of a subset of p6 ranges 21:03
jdv79 i was thinking maybe just go totally simple in static meta and escape to hooks for anyting else
mst since that seems like the simple way to get things to match up
leont I'd think the config issue has a higher priority (it affects way more dists), but the build issue should be tackled too
jdv79: how do you imagine those hooks to be sane? The installer needs to know all dependencies 21:04
jdv79 i feel like i'm not up to speed enough with you p6 toolchain guys to be useful. 21:05
mst this isn't mostly about p6 at all as such, just the requirements of writing installers in general
jdv79 how would they be insane?
mst I don't understand how a hook can influence dependencies 21:06
in a way that allows the builder to resolve them sensibly
leont jdv79: hooks are typically things with side-effects but no result value
We rather want the opposite in this case
jdv79 ok, so wrong vocab. i'm talking about being able to gen metadata. 21:07
essentially just do something like search.cpan.org/~dagolden/CPAN-Meta...mic_config 21:09
is that not a good idea here?
mst every time you say 'just do' in a toolchain conversation you accidentally brush all the sharp edges that will fuck you later under the rug
I am actually physically twitching every time you say 'just' here
jdv79 yeah. sorry. i'll stop. 21:10
maybe i should just write some code and show it - that might be easier
mst seriously though, 'just' in a toolchain conversation is usually more of a harbinger of disaster than 'hold my beer' ;)
jdv79 well, we're still kinda in hand wavy stages aren't we? or have we progressed beyond that now. 21:13
ugexe: is zef back in action? and does it have cpan support yet? 21:16
ugexe yes, and not really. if you can get your server back online i can check again. otherwise it at least will download perl5 Acme::Goatse, extract it, and try to install it 21:18
jdv79 ha, ok. 21:19
leont I think we're doing fine at identifying issues, and are already suggesting solutions; at least we're doing things in the right order 21:20
mst points at the first thing in the topic
mst added that for a bloody reason
sjn "Justin joustes just for Justice" # mst-twitch-of-death 21:25
mst "... oh, dear, did I just twitch so hard I stabbed you in the eyesocket with this butter knife? terribly sorry, old boy ..." 21:27
sjn hehe
btw, 21:29
I'm being Warnock'ed with github.com/sjn/toolchain-bikeshed/...aster/doc/ # I'd like to make this into something useful; Feedback wanted
leont autarch: will try to look at it tomorrow 21:31
autarch leont: thanks 21:32
nine is actually thinking that zef is better than panda by now 21:34
mst I'm starting to suspect that zef certainly has a better chance of evolving into a 'real' client (for fuzzy values of real not in any way to criticise its current capabilities) 21:36
22:05 ranguard joined 22:08 llfourn_ joined 22:48 llfourn joined 22:53 leont joined 22:57 pnu joined, flussence joined

Powered by Cro and the Raku® Programming Language.

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

Thank you!