Perl 6 - the future is here, just unevenly distributed

IRC log for #perl6-toolchain, 2016-02-15

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

All times shown according to UTC.

Time Nick Message
07:04 japhb joined #perl6-toolchain
07:04 llfourn joined #perl6-toolchain
07:04 MadcapJake joined #perl6-toolchain
07:04 autarch joined #perl6-toolchain
07:17 FROGGS joined #perl6-toolchain
12:24 leont joined #perl6-toolchain
13:06 sufrostico joined #perl6-toolchain
14:27 sufrostico joined #perl6-toolchain
15:19 leont joined #perl6-toolchain
17:17 hankache joined #perl6-toolchain
17:45 Kassandry joined #perl6-toolchain
18:06 sufrostico joined #perl6-toolchain
18:33 FROGGS joined #perl6-toolchain
19:31 nine I wonder how the replacement for Build.pm should look like. Now that require's fixed in rakudo, I cannot even get the hack panda's using to work again.
19:34 sufrostico joined #perl6-toolchain
19:34 sufrosti1o joined #perl6-toolchain
19:50 tony-o_ isn't the replacement the hooks?
19:55 nine which hooks?
20:06 ugexe i think he means the replacement is as simple as the very lacking documentation on special directory `hooks/`. To summarize: hooks/ would contain executable perl6 code that would be executed at various stages. this is how zef currently treats Build.pm (as an executable script)
20:07 ugexe the way panda does it currently has no separation of itself and Build, so whacky native call errors during Build can cause havok on a panda smoke test
20:08 ugexe but by taking the simple route of scripts in hooks/ (maybe declaring them in the meta) is it easily extends to any part of the install process (parts CURI wouldnt care about, but packagers would)
20:09 ugexe and they can be created/executed without any dependencies
20:11 ugexe this solution requires 2 things to be thought out first: 1. names hooks (including -fixes like pre/post/ok/failure i.e. a pre-Build hook, post-Build hook) 2. What information gets passed to each hook, and how (usually an ENV var but whatever works)
20:17 ugexe https://github.com/ugexe/zef/tree/ec1b99f4325f2fad98bab811ece3b0ad549e9251/hooks is a very basic implementation. but it may be better to declare them in META itself so you can name your files anything, and just attach a 'build-time' tag (see s22 %?RESOURCES)
20:17 llfourn joined #perl6-toolchain
20:24 ugexe In the mean time, the following works for executing Build.pm with the new request changes: `my $dir = "/home/dist"; run perl6 -I. -Ilib -e "require <Build.pm>; ::('Build').new.build('$dir'); exit(0);";`
20:35 cognominal joined #perl6-toolchain
21:01 nine Actually the gold standard would be to not need any hooks at all because we have declarative ways for everything a dist needs for building
21:04 * perlpilot starts to get a Dist::Zilla feeling
21:04 ugexe gold standard for a package manager, not for core
21:05 autarch I started playing with a Dist::Zilla type thing but got distracted by test infrastructure
21:05 autarch https://github.com/autarch/perl6-Dist-Wocky
22:14 flussence I've pared my toolchain wishlist down to one item: something that allows me to write "./configure && make && make DESTDIR=$foo install" in any perl6 module directory with a reasonably high success rate. My reasoning is that if that's possible, everything else is in a sane state.
22:24 sufrostico joined #perl6-toolchain
22:30 autarch flussence: do you literally mean "make" or just something like that?
22:30 autarch cause I'd really hate to see EUMM6
22:31 autarch and I suspect in an ideal world there's nothing like configure either - for the vast majority of modules, you don't need to execute a script to configure it, you just need some metadata
22:31 autarch I could see building in an escape hatch for "execute this to get this config value" for some use cases

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