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 28 August 2016.
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:08
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:10
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:17
instead of sticking such build scripts in resources/ 01:18
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:26
Maybe "perlopts": {"run": {"by-kernel.name": {"windows": "perlopts.bat", "default": "perlopts.sh"}}} 06:29
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:31
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. 06:32
I wrote down my thoughts so far in github.com/perl6/toolchain-bikeshe...r/build.md 07:46
07:47 domidumont joined
nine @all: feel free to add your thoughts :) 07:50
07:52 domidumont joined 08:01 leont joined
lizmat nine: misspellings in: "The plattform specifica hashes" 08:37
quickly glance through it otherwise, looks sane to me 08:38
*glanced
nine lizmat: thanks, fixed it :) 08:41
12:04 ilbot3 joined
moderator 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
12:21 domidumont joined 13:05 domidumont joined
stmuk_ are there any tests for curli uninstall? 13:23
nine nope 13:24
ugexe zef has an uninstall test: github.com/ugexe/zef/blob/master/x...tall.t#L89 14:22
nine ugexe: incidentally the test does not cover removal of the short-name lookup files 14:27
ugexe nine: true, but that is because its outside the scope of a package manager 15:40
nine Of course :) I just thought it funny that your tests cover exactly the bits that are working :) 15:43
mst *lolsob* 15:44
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:51
Next steps: * have a look at a lot more Build.pm files * ask perl/#toolchain for input 15:52
16:05 edehont joined 16:46 lizmat joined
nine I added my results of the ecosystem Build.pm survey to github.com/perl6/toolchain-bikeshe...r/build.md 16:54
mst I do wonder whether this is actually a good idea 16:59
and whether we'd be better off with a configure_requires type mechanism
and an explicit protocol for 'how to run a configure script'
I mean, like, maybe something again to the perl5 Build.PL/Build protocol, except designed from the ground up to not be terrible 17:00
JimmyZ hook/plugin support? 17:02
mst eh? 17:03
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:14
mst nine: well, the whole point of configure_requires is that that doesn't happen. 17:15
17:15 leont joined
nine mst: care to elaborate? 17:15
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:16
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:20
leont doesn't know the context, but anything that leads to leas Build.pm is a good thing in his book 17:21
mst nine's current proposal is "try and specify a mini-language in JSON that replaces Build.pM" 17:22
I'm suggesting we start with adding configure_requires so we're not tied to a specific set of JSON structures
nine leont: github.com/perl6/toolchain-bikeshe...r/build.md 17:23
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
The other direction is flat out impossible.
leont Yeah
Turing completeness is a double-edged sword 17:35
mst nine: so, what I'm basically thinking is 17:42
configure_requires Builder::FromJSON
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.
mst and then *that* implements the JSON stuff
so that when (2) happens, people can just move to Builder::FormJSON<api:v2> or whatever
also it means people don't end up accidentally relying on a particular installer (see Build.pm) 17:44
nine: does that make some sort of sense? 17:45
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:47
mst eh? 17:48
nine: configure_requires gets you the tools required for the configure phase
build_requires is the tools required for the 'make' phase
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.
mst I'm confused. you have makefile substitutions in your JSON thingy 17:50
surely .build() then is 'run make'
17:50 domidumont joined
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:50
mst 17:59 < mst> and an explicit protocol for 'how to run a configure script' 17:51
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
so, like, 'perl6 configure.pl6' and the installer is just required to've satisfied configure_requires first
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
you have 'configure_via: "Distribution::Configurator::RunConfigureScript"
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.
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"
mst yes, that's exactly the sort of configure.pl6 I'd been thinking about
yes, maybe you remove that later
but it seems to me that 'builder runs inside the install tool' is asking for 'fun' 17:54
I'd rather start off with a two line static configure script 17:55
and then consider trying to be more clever later
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:56
mst to me, it's easy to add a protocol to the installers, it's much harder to take it back, so :) 17:57
18:07 leont joined
nine mst: this discussion definitely needs more input 18:08
mst nine: I do now see what you mean though
I guess the question is "which corner is easiest to escape from if we paint ourselves into it" 18:09
nine exactly!
leont devil's pie v1 had my favorite configuration format ever, too bad it died 18:12
mst hm?
leont Basically it was s-expressions, it was pretty much a non-turning-complete programming language
(actually, it seems it probably was turing-complete, but it felt restricted in the right way) 18:14
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:17
A DSL (in the original meaning, not the Ruby one) may be way more convenient for anyone trying to write in it. 18:18
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:19
Good thing is: converting from JSON to another syntax is easy. 18:20
mst right, I mean, my original vision was that your configure.plg6 18:23
would do
use BuildDSL;
<rest of file in BuildDSL format>
18:51 camelia joined 18:52 sjn joined 18:53 avar joined 18:58 DrForr joined
nine Just pushed an implementation of my proposal in github.com/rakudo/rakudo/commit/defd764e04 18:58
mst wait, what 19:02
nine: ok, so, whether we do "module installers run" or "script installers run"
I am *strongly* against putting this into rakudo proper until we've actually shaken it out in the wild
that will concrete us into a corner :P 19:03
the whole point of configure_requires was that we learned the hard way not to do that at all costs :P
JimmyZ nine: maybe s/MakeFromJSON/FromJSON/ better name? :) 19:04
mst JimmyZ: MakeFromJSON generates a Makefile from a JSON spec
JimmyZ: the name seems perfect to me
JimmyZ nine: wrong, should be just FromJSON haha 19:05
mst JimmyZ: what
JimmyZ not above I said
I meant not s/MakeFromJSON/FromJSON/
mst what
nine mst: it's just a branch :)
mst nine: yeah, just being paranoid BEFORE we merge things 19:06
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.
mst JimmyZ: yes, and MakeFromJSON is a better name. 19:08
nine: I think I would have raccoon's parts as Raccoon::
to indicate "these are for the tool, don't depend on them for anything else" 19:09
then raccoon can focus on being a minimal thing
that gets used for simple cases, or to bootstrap a smarter installer for more complicated cases
nine Right now it's 49 lines of code. Not much to put into modules :)
mst mm 19:10
so, I'm convinced we're not currently being sufficiently paranoid 19:11
but I'm not convinced I've thought it through enough to work out what sufficiently paranoid would imply
nine Good assumption
19:26 ugexe joined
nine Updated build.md with the Distribution::Builder proposal 19:27
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:33
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
Clearly we'll need a meta build system and a meta language to describe it and....
mst and suddenly a configure.pl6 that does 19:38
class MyBuilder extends Dsitribution::Builder with GitCloneRole {} 19:39
starts to seem rather easier :P
nine You enjoy that, don't you? ;)
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:40
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:42
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
OTOH that may have been the strategy that brought us Build.pm in the first place :P
mst well, that's the thing, if the horrible lives in configure.pl6 and build.pl6 scripts 19:57
it doesn't end up in rakudo core :)
leont was planning to port BG to p6 when it's ready, but it's a very-long term process -_-
JimmyZ BG? 20:08
leont Build::Graph
It's a kind of make, but without forking out to the shell (because portability) 20:10
Wrote it in p5, and started a port to p6, but ENOTUITS
hoelzro nine: I saw that you mentioned Native::Resources::Build in build.md; I wrote up an explanation of what it's for here: hoelz.ro/blog/distributing-helper-l...l6-modules 20:19
nine hoelzro: ah...looks kinda dated 20:32
hoelzro: github.com/rakudo/rakudo/blob/racc...SON.pm#L44 20:33
hoelzro: github.com/niner/Inline-Perl5/blob...l5.pm6#L18 20:34
hoelzro oh, handy 20:44
did the spec change so that you could specify a single shared object base name in resources in META6.json? 20:45
nine hoelzro: Dec 22 commit ddb8e523cfc5ae77353f7b5f7bf4e068de1d1adb 20:49
hoelzro nine: right, but how do I tell the installer via META6.json that my helper is in linenoise.$EXT? 20:52
nine hoelzro: github.com/niner/Inline-Perl5/blob...A.info#L14 20:53
It's by convention. File names in resources/libraries/ will be expanded
"libraries/p5helper" -> "libraries/libp5helper.so" on Linux and "libraries\\p5helper.dll" on Windows
hoelzro ahhh 20:54
that's up to the installer, though, right?
that behavior isn't spec'd?
nine It's not spec'd because I'm lazy and always hope others will document it. 20:55
hoelzro heh =)
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
nine done 20:56
Gave me an opportunity to remove some trailing whitespace ;)
hoelzro =)
mst Blog post: The PSIXDISTS experiment: Test populating /Perl6/ on 21:27
CPAN: shadow.cat/blog/matt-s-trout/the-ps...xperiment/
jdv79: ^^ I AM PUTTING THE WHINERS ON NOTICE 21:35
jdv79 whos whining? 21:39
im drinking bt i skimmed it and i assume its good. tgank you sir! 21:41
21:43 edehont joined
[Coke] should we be picking zef or panda to "win"? 22:29

Powered by Cro and the Raku® Programming Language.

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

Thank you!