Perl 6 - the future is here, just unevenly distributed

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

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

All times shown according to UTC.

Time Nick Message
01:08 ugexe nine: declaring the entire run command is going to get messy because you have to allow different commands for different OS, or versions, etc
01:10 ugexe i imagine speccing a bunch of ENV vars and promising to run some script the meta data points at with that ENV is closer to the core's responsibility
01:17 ugexe i guess you can just point the run at whatever build script to do that logic, but its probably a good idea to spec such a location out anyway in case it needs to be installed or indexed
01:18 ugexe instead of sticking such build scripts in resources/
06:26 nine Good points. We definitely need some way to differentiate between OSes. I'm also inclined to keep a way to just give it a command, since that's exactly what I need in Inline::Perl5, so others will need the same.
06:29 nine Maybe "perlopts": {"run": {"by-kernel.name": {"windows": "perlopts.bat", "default": "perlopts.sh"}}}
06:31 nine Same as was envisioned in S22 for resources: if the value is a hash it can futher specify options. One could even nest them: "by-kernel.name": {"linux": {"by-kernel.version": {4: "new-kernel.sh", 2.6: "old-kernel.sh", "default": "ancient-kernel.sh"}}}
06:32 nine I'm also taking a clue from systemd-init here: yes, you need quite a lot of directives to be able to manage all services, but it's doable and still so much better than shell scripts.
07:46 nine I wrote down my thoughts so far in https://github.com/perl6/toolchain-bikeshed/blob/master/build.md
07:47 domidumont joined #perl6-toolchain
07:50 nine @all: feel free to add your thoughts :)
07:52 domidumont joined #perl6-toolchain
08:01 leont joined #perl6-toolchain
08:37 lizmat nine: misspellings in: "The plattform specifica hashes"
08:38 lizmat quickly glance through it otherwise, looks sane to me
08:38 lizmat *glanced
08:41 nine lizmat: thanks, fixed it :)
12:04 ilbot3 joined #perl6-toolchain
12:04 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
12:21 domidumont joined #perl6-toolchain
13:05 domidumont joined #perl6-toolchain
13:23 stmuk_ are there any tests for curli uninstall?
13:24 nine nope
14:22 ugexe zef has an uninstall test: https://github.com/ugexe/zef/blob/master/xt/install.t#L89
14:27 nine ugexe: incidentally the test does not cover removal of the short-name lookup files
15:40 ugexe nine: true, but that is because its outside the scope of a package manager
15:43 nine Of course :) I just thought it funny that your tests cover exactly the bits that are working :)
15:44 mst *lolsob*
15:51 nine With all contributions to build.md so far being typo fixes, I just go on assuming that I'm not too far off the mark :)
15:52 nine Next steps: * have a look at a lot more Build.pm files * ask perl/#toolchain for input
16:05 edehont joined #perl6-toolchain
16:46 lizmat joined #perl6-toolchain
16:54 nine I added my results of the ecosystem Build.pm survey to https://github.com/perl6/toolchain-bikeshed/blob/master/build.md
16:59 mst I do wonder whether this is actually a good idea
16:59 mst and whether we'd be better off with a configure_requires type mechanism
16:59 mst and an explicit protocol for 'how to run a configure script'
17:00 mst I mean, like, maybe something again to the perl5 Build.PL/Build protocol, except designed from the ground up to not be terrible
17:02 JimmyZ hook/plugin support?
17:03 mst eh?
17:14 nine mst: hard to say. For example, people do want to download something during configure or build. So for X people we will end up with X different implementations of "download something" and only some of them will support a way to redirect the download to a local folder allowing for a sandboxed build without network access.
17:15 mst nine: well, the whole point of configure_requires is that that doesn't happen.
17:15 leont joined #perl6-toolchain
17:15 nine mst: care to elaborate?
17:16 mst instead you end up with 2 or 3, then one becomes the standard for a while, then later there'll be a gradual shift to the new thing
17:20 nine So instead of pointing at the required resources in the META data, we'd point at modules able to fetch those resources and have calls to those modules in the custom Build code?
17:21 * leont doesn't know the context, but anything that leads to leas Build.pm is a good thing in his book
17:22 mst nine's current proposal is "try and specify a mini-language in JSON that replaces Build.pM"
17:22 mst I'm suggesting we start with adding configure_requires so we're not tied to a specific set of JSON structures
17:23 nine leont: https://github.com/perl6/toolchain-bikeshed/blob/master/build.md
17:34 nine The huge advantage of a non-touring-complete build definition is that if it turns out to be a bad idea, it's always possible to convert it to Perl 6 code.
17:34 nine The other direction is flat out impossible.
17:34 leont Yeah
17:35 leont Turing completeness is a double-edged sword
17:42 mst nine: so, what I'm basically thinking is
17:42 mst configure_requires Builder::FromJSON
17:42 nine Two lessions I've personally learned from Perl 5's ecosystem: 1. people are terrible at writing code for building their modules (me being the worst of all). 2. you will get it wrong on the first try. And probably the second and third, too.
17:42 mst and then *that* implements the JSON stuff
17:42 mst so that when (2) happens, people can just move to Builder::FormJSON<api:v2> or whatever
17:44 mst also it means people don't end up accidentally relying on a particular installer (see Build.pm)
17:45 mst nine: does that make some sort of sense?
17:47 nine configure_requires sounds too generic for this purpose, as the installer still doesn't know what module to use to process the build. But a "build_system": "Distribution::Builder" or whatever might work.
17:48 mst eh?
17:48 mst nine: configure_requires gets you the tools required for the configure phase
17:48 mst build_requires is the tools required for the 'make' phase
17:49 mst generally my build_requires is minimal cuz I generated a Makefile that handles whatever I need during configure
17:49 nine With META data like {"build_system": "Distribution::Builder::FromJSON", "build": { ... }} the installer knows to load Distribution::Builder::FromJSON and run a .build($distribution) method on it.
17:50 mst I'm confused. you have makefile substitutions in your JSON thingy
17:50 mst surely .build() then is 'run make'
17:50 domidumont joined #perl6-toolchain
17:50 nine With just {"configure_requires: ["LibraryMake", "Resource::Fetcher", "Distribution::Builder::FromJSON"], "build": {...}} how would the installer know how to create the Makefile needed to run make?
17:51 mst 17:59 < mst> and an explicit protocol for 'how to run a configure script'
17:51 mst 18:00 < mst> I mean, like, maybe something again to the perl5 Build.PL/Build  protocol, except designed from the ground up to not be terrible
17:51 mst so, like, 'perl6 configure.pl6' and the installer is just required to've satisfied configure_requires first
17:52 nine The "build_system" key and a Distribution::Builder role could be that protocol
17:52 mst I guess, and then if you want to do configure.pl6
17:52 mst you have 'configure_via: "Distribution::Configurator::RunConfigureScript"
17:52 nine But the point of the exercise is that most people won't have to write Perl 6 code at all for their module's build.
17:53 mst have you seen Module::Build::Tiny ?
17:53 nine Even if the configure.pl6 would just be "use Distribution::Builder::FromJSON; Distribution::Builder::FromJSON.new(how the hell do I get at the META data?).build"
17:53 mst yes, that's exactly the sort of configure.pl6 I'd been thinking about
17:53 mst yes, maybe you remove that later
17:54 mst but it seems to me that 'builder runs inside the install tool' is asking for 'fun'
17:55 mst I'd rather start off with a two line static configure script
17:55 mst and then consider trying to be more clever later
17:56 nine Like I said, it's easy to generate that configure script. It's much harder to take it back. So starting without it seems the safer choice?
17:57 mst to me, it's easy to add a protocol to the installers, it's much harder to take it back, so :)
18:07 leont joined #perl6-toolchain
18:08 nine mst: this discussion definitely needs more input
18:08 mst nine: I do now see what you mean though
18:09 mst I guess the question is "which corner is easiest to escape from if we paint ourselves into it"
18:09 nine exactly!
18:12 leont devil's pie v1 had my favorite configuration format ever, too bad it died
18:12 mst hm?
18:12 leont Basically it was s-expressions, it was pretty much a non-turning-complete programming language
18:14 leont (actually, it seems it probably was turing-complete, but it felt restricted in the right way)
18:17 leont My main point being, we're awesome at parsing, and I'm not sure this problem matches well with what JSON is designed for
18:18 leont A DSL (in the original meaning, not the Ruby one) may be way more convenient for anyone trying to write in it.
18:19 nine Oh I'd like to see something less tedious to write than JSON. I'm just not the one to build that and now is probably not the time to do it. Not yet.
18:20 nine Good thing is: converting from JSON to another syntax is easy.
18:23 mst right, I mean, my original vision was that your configure.plg6
18:23 mst would do
18:23 mst use BuildDSL;
18:23 mst <rest of file in BuildDSL format>
18:51 camelia joined #perl6-toolchain
18:52 sjn joined #perl6-toolchain
18:53 avar joined #perl6-toolchain
18:53 avar joined #perl6-toolchain
18:58 DrForr joined #perl6-toolchain
18:58 nine Just pushed an implementation of my proposal in https://github.com/rakudo/rakudo/commit/defd764e04
19:02 mst wait, what
19:02 mst nine: ok, so, whether we do "module installers run" or "script installers run"
19:02 mst I am *strongly* against putting this into rakudo proper until we've actually shaken it out in the wild
19:03 mst that will concrete us into a corner :P
19:03 mst the whole point of configure_requires was that we learned the hard way not to do that at all costs :P
19:04 JimmyZ nine: maybe s/MakeFromJSON/FromJSON/ better name? :)
19:04 mst JimmyZ: MakeFromJSON generates a Makefile from a JSON spec
19:04 mst JimmyZ: the name seems perfect to me
19:05 JimmyZ nine: wrong, should be just FromJSON haha
19:05 mst JimmyZ: what
19:05 JimmyZ not above I said
19:05 JimmyZ I meant not s/MakeFromJSON/FromJSON/
19:05 mst what
19:05 nine mst: it's just a branch :)
19:06 mst nine: yeah, just being paranoid BEFORE we merge things
19:07 JimmyZ I mean Builder::FromJSON :)
19: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.
19:08 mst JimmyZ: yes, and MakeFromJSON is a better name.
19:08 mst nine: I think I would have raccoon's parts as Raccoon::
19:09 mst to indicate "these are for the tool, don't depend on them for anything else"
19:09 mst then raccoon can focus on being a minimal thing
19:09 mst that gets used for simple cases, or to bootstrap a smarter installer for more complicated cases
19:09 nine Right now it's 49 lines of code. Not much to put into modules :)
19:10 mst mm
19:11 mst so, I'm convinced we're not currently being sufficiently paranoid
19:11 mst but I'm not convinced I've thought it through enough to work out what sufficiently paranoid would imply
19:11 nine Good assumption
19:26 ugexe joined #perl6-toolchain
19:27 nine Updated build.md with the Distribution::Builder proposal
19:33 nine I'm thinking about the "git clone some test data" use case. Unless we deem that functionality to be of sufficient importance to provide in general, one could implement it as a subclass of Distribution::Builder::MakeFromJSON that overrides configure()
19:34 nine Or make that reusable as a Role for use by different build systems? They all will want to be able to fetch resources.
19:34 nine Clearly we'll need a meta build system and a meta language to describe it and....
19:38 mst and suddenly a configure.pl6 that does
19:39 mst class MyBuilder extends Dsitribution::Builder with GitCloneRole {}
19:39 mst starts to seem rather easier :P
19:39 nine You enjoy that, don't you? ;)
19:40 nine Except of course that we'd need a configure.pl6 and a build.pl6. Otherwise mst will start ranting about us doing too much at configure time. Unless we want to tie ourselves to make.
19:42 * leont would argue for what he did in Build::Graph (documentation coming soon), having a configure phase building a build-graph and all other phases using that
19:44 nine Of course the winning strategy for me seems to be: implement something that could almost work but is horrible enough so knowledgable people will come in and write the real thing.
19:44 nine OTOH that may have been the strategy that brought us Build.pm in the first place :P
19:57 mst well, that's the thing, if the horrible lives in configure.pl6 and build.pl6 scripts
19:57 mst it doesn't end up in rakudo core :)
19:57 * leont was planning to port BG to p6 when it's ready, but it's a very-long term process -_-
20:08 JimmyZ BG?
20:08 leont Build::Graph
20:10 leont It's a kind of make, but without forking out to the shell (because portability)
20:10 leont Wrote it in p5, and started a port to p6, but ENOTUITS
20:19 hoelzro nine: I saw that you mentioned Native::Resources::Build in build.md; I wrote up an explanation of what it's for here: http://hoelz.ro/blog/distributing-helper-libraries-with-perl6-modules
20:32 nine hoelzro: ah...looks kinda dated
20:33 nine hoelzro: https://github.com/rakudo/rakudo/blob/raccoon/lib/Distribution/Builder/MakeFromJSON.pm#L44
20:34 nine hoelzro: https://github.com/niner/Inline-Perl5/blob/master/lib/Inline/Perl5.pm6#L18
20:44 hoelzro oh, handy
20:45 hoelzro did the spec change so that you could specify a single shared object base name in resources in META6.json?
20:49 nine hoelzro: Dec 22 commit ddb8e523cfc5ae77353f7b5f7bf4e068de1d1adb
20:52 hoelzro nine: right, but how do I tell the installer via META6.json that my helper is in linenoise.$EXT?
20:53 nine hoelzro: https://github.com/niner/Inline-Perl5/blob/master/META.info#L14
20:53 nine It's by convention. File names in resources/libraries/ will be expanded
20:53 nine "libraries/p5helper" -> "libraries/libp5helper.so" on Linux and "libraries\p5helper.dll" on Windows
20:54 hoelzro ahhh
20:54 hoelzro that's up to the installer, though, right?
20:54 hoelzro that behavior isn't spec'd?
20:55 nine It's not spec'd because I'm lazy and always hope others will document it.
20:55 hoelzro heh =)
20:55 hoelzro well, I think in that case you can remove the Native::Resources part from your build.md document - I think it's outlived its usefulness
20:56 nine done
20:56 nine Gave me an opportunity to remove some trailing whitespace ;)
20:56 hoelzro =)
21:27 mst Blog post: The PSIXDISTS experiment: Test populating /Perl6/ on
21:27 mst CPAN: http://shadow.cat/blog/matt-s-trout/the-psixdists-experiment/
21:35 mst jdv79: ^^ I AM PUTTING THE WHINERS ON NOTICE
21:39 jdv79 whos whining?
21:41 jdv79 im drinking bt i skimmed it and i assume its good.  tgank you sir!
21:43 edehont joined #perl6-toolchain
22:29 [Coke] should we be picking zef or panda to "win"?

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