Perl 6 - the future is here, just unevenly distributed

IRC log for #perl6-toolchain, 2016-08-31

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

All times shown according to UTC.

Time Nick Message
01:21 mst jdv79: some perl5 people did, this is their last chance :D
01:22 tadzik joined #perl6-toolchain
01:48 ilbot3 joined #perl6-toolchain
01:48 Topic for #perl6-toolchain is now Fire is step THREE! | https://github.com/perl6/toolchain-bikeshed | Channel logs: http://irclog.perlgeek.de/perl6-toolchain/today | useful prior art: https://metacpan.org/pod/CPAN::Meta::Spec
01:55 tadzik joined #perl6-toolchain
06:36 domidumont joined #perl6-toolchain
06:42 domidumont joined #perl6-toolchain
07:18 sivoais joined #perl6-toolchain
07:28 sivoais joined #perl6-toolchain
07:29 leont joined #perl6-toolchain
08:33 ribasushi joined #perl6-toolchain
09:14 domidumont joined #perl6-toolchain
13:07 domidumont joined #perl6-toolchain
14:09 ugexe i think it'll be more useful to define a format/spec that something in `build-depends` is expected to understand rather than that + pass in a Builder module
14:09 mst hm?
14:10 nine ugexe: care to elaborate?
14:10 ugexe because you can expand such a format into the general hook environment and provide those facilities for testing, uninstall, etc
14:11 domidumont joined #perl6-toolchain
14:11 perlpilot joined #perl6-toolchain
14:13 ugexe it can still be made to take a builder plugin or whatever, but the meta spec should first be generalized enough to be used for other phases of the process
14:13 mst ugexe: that doesn't help, I'm afraid
14:13 mst I can't figure out what shape of thing you're trying to propose here
14:15 mst I mean, I think we probably want to have configure and build and test and runtime requirements, ala CPAN::Meta::Spec
14:16 mst *personally* I think the protocol for calling build steps is probably best being defined as "execute this process", simply because otherwise it would be very easy for people to start assuming things that only make sense inside the context of their specific installer of choice
14:16 mst and I really don't want 'only installs with panda' type things to happen again
14:16 ugexe right, im proposing the opposite of that
14:17 mst ok, then please elaborate
14:17 * nine is just happy to see the discussion continue
14:17 mst and explain why it's less likely to paint us into a corner in the short to medium term, which is my main worry
14:17 mst if somebody else finds a more easily escapable corner than mine, I'm all for forgetting everything I've said ;)
14:19 ugexe you promise to provide an environment with whatever ENV vars at each phase of an install/uninstall process. ultimately it does something like `run hooks/uninstall-post.pl6, :env(%UNINSTALL_ENV)`
14:20 ugexe what nine is doing can be built on top of that naturally, but it can be extended to be used for other parts
14:21 mst ah, you're talking about "your protocol is these env vars and then we run X.pl6" for each stage?
14:21 ugexe yes, although it doesnt have to be ENV vars. thats just the obvious way
14:22 ugexe but it also lets those hooks have access to things like the current install status of other parts of the install chain
14:22 ugexe similar to nix
14:23 mst yeah
14:25 mst I like
14:25 mst and it also means that if a given implementation of the internals of said scripts turns out to be a terrible idea
14:25 mst we can discard it and move on
14:26 perlpilot joined #perl6-toolchain
14:28 ugexe right, build the generalized spec into rakudo. then you can have a rakudo/lib/Build.pm as a default (that could later be discarded to the ecosystem) that understands how to use the declarative build syntax
14:29 mst I would prefer to not do that, and to instead have configure.pl6 and build.pl6 scripts and have the first cut at declarative build syntax be a configure_requires dep
14:30 mst because of the
14:30 mst 20:38 < mst> and suddenly a configure.pl6 that does
14:30 mst 20:39 < mst> class MyBuilder extends Dsitribution::Builder with GitCloneRole {}
14:30 mst 20:39 < mst> starts to seem rather easier :P
14:30 mst note
14:30 mst this could be a single script to begin with
14:30 nine Mind that if our interface is designed around running user-supplied scripts, the directory structure those scripts are run in is also part of the interface.
14:30 ugexe thats how zef implemented hooks long ago
14:30 mst hmmm
14:30 ugexe hooks/[pre/post]?-$phase.pl6
14:31 mst I would not be totally averse to having a very basic build class in core that only handles the App::ModuleBuild::Tiny level of stuff
14:31 mst i.e. just lib/ and bin/
14:31 nine We don't need any build class at all for that
14:31 mst because CUR takes a tree of that format for install?
14:32 nine Custom build steps are only needed for generating or modifying files during the build. If all you need is get those files installed, you're already good with some meta data.
14:33 mst and said code has already shipped in a production rakudo?
14:33 nine Yes. That's why most Perl 6 dists actually don't have a Build.pm at all.
14:33 mst right
14:34 ugexe the other thing to keep in mind is how to track which files are part of which phase. so you can have a MANIFEST that knows which files were included originally, which were built at build-time, etc
14:34 nine See https://github.com/hankache/Acme-Cow
14:34 mst nine: so how is that meta data read? does CUR just handle it internally?
14:35 nine mst: https://github.com/rakudo/rakudo/blob/nom/src/core/Distribution.pm#L119
14:35 mst aha
14:35 mst cool
14:36 nine Another reason why I don't fancy calling custom scripts that much. Distribution objects are very handy. Being able to pass them to some method simplifies things a lot
14:36 mst hmmm
14:37 mst oh, here's a thought
14:37 mst a basic Distribution::Builder that provides no-op configure() and build() stages, a standard test() and install() that are basically empty
14:38 ugexe install() probably doesnt fit in that though
14:38 mst well, maybe files-to-install() or something
14:38 mst to give the builder a chance to report things it compiled?
14:39 ugexe well so you can install to multiple CURIs or something
14:39 mst or maybe *it* is expected to return a Dsitrubition object
14:40 mst but I still think e.g. the MakeFromJSON should be shipped separately
14:40 mst rakudo can try and define an API
14:40 mst but I don't want any non-trivial implementations of it in core until they've lived in the outside world for a while
14:41 mst (and even then ... the saga of adding and then removing Module::Build in perl core was no fun for anybody)
14:41 mst nine: oh, also
14:41 mst my argument about a configure.pl6 above
14:41 mst it strikes me that we could support inc/MyBuilder.pm for that
14:43 mst which I think maybe works out nicely
14:43 mst with the understanding that people will need do with something like
14:43 mst with Distribution::Build::API<ver:1.0>
14:44 mst ort something
14:44 mst so we can upgrade the API the core thing provides later
14:44 mst nine: obviously, being able to -not- have a configure.pl6 is totally dependent on having lexical imports working :D
14:49 nine mst: MakeFromJSON is meant to be shipped separately. I just put it into the branch because it's an easier way to show it to people
14:49 mst nine: you didn't say that the first time I went "eep" about it being in the branch. but cool :)
14:50 nine 21:07 < nine> I want raccoon to ship with rakudo as a bootstrapping and packaging tool. Distribution::Builder::MakeFromJSON is not necessary for that. As long as we can bootstrap a toolchain that  allows for installing it.
14:51 mst yes, I remember that, but 'not necessary' is not the same as 'I agree that its presence in the branch is only for showing, and we should remove it before merge'
14:51 nine I meant that raccoon without MakeFromJSON is still enough for installing Distribution::Builder::MakeFromJSON, so I'm completely fine with it being a separate dist.
14:51 nine well now we're on the same page :)
14:52 nine That dists that just install the shipped files as is don't need any custom build code right now is the reason why we can ship Distribution::Builder::MakeFromJSON in its own dist
14:53 mst right
14:54 mst ugexe: also, if we do it this way, we can have hook scripts be provided by a builder role that your inc/MyBuilder can consume
14:54 mst which I *think* simplifies things?
14:55 domidumont joined #perl6-toolchain
16:30 perlpilot joined #perl6-toolchain
17:01 leont joined #perl6-toolchain
17:10 lizmat joined #perl6-toolchain
18:00 leont joined #perl6-toolchain
18:47 domidumont joined #perl6-toolchain
18:56 leont joined #perl6-toolchain
19:43 perlpilot joined #perl6-toolchain
20:26 [Coke] Hey. we have a user in #perl6 who is trying to implement a curl installer. he's not a bash guy, DrForr convinced him to give it a shot; if he stops by looking for guidance, please be nice. ;)
20:27 [Coke] er, :)
20:27 mst 'a curl installer' ?
20:28 mst oh, right, I see
20:31 DrForr Yeah, my fault :) He was going on about how Meteor and .. well, perlbrew does this 'curl | bash' line; I'm all for ease of installation, and he seemed enthusiastic enough that we weren't going to burn him out *too* soon :)
20:31 [Coke] yah, feel free to chime in in #perl6, doc. :P
20:41 mst aaaaaaaaaaaaaaaaaaaaaaaaaa
20:43 [Coke] mst: calm. blue. ocean.
20:43 mst [Coke]: MY GOD IT'S FULL OF SHARKS
20:43 [Coke] mmhehehe.
20:44 mst (you'll find that, actually, I rant because it's therapeutic)
20:44 [Coke] I was trying super hard to be positive and now I have to leave work, so you have fun now, ok? ;)
20:44 mst I'm being positive over there
20:44 mst it'll be fine
20:44 [Coke] I ... trust you.
20:44 [Coke] (pause only for dramatic effect. :)
20:45 mst http://trout.me.uk/areyousure.jpg
20:46 DrForr I had to explain this same problem in a different guise to my team last month.
20:48 mst DrForr: .oO 'eval $(curl -L thing | sh)'
20:48 mst what could possibly go wrong
20:50 DrForr "Hold my beer."
21:57 ugexe bbbbut windows curl alias doesn't work with -L!
21:58 ugexe C:\Users\Nick\Documents\GitHub>powershell curl -L xxx
21:58 ugexe Invoke-WebRequest : A parameter cannot be found that matches parameter name 'L'.
21:59 * ugexe is always tryign to find the magic invocation that works on GNU, BSD, and Win32 for various cli tools
22:07 stmuk joined #perl6-toolchain

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