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 30 August 2016.
mst jdv79: some perl5 people did, this is their last chance :D 01:21
01:22 tadzik joined 01:48 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
01:55 tadzik joined 06:36 domidumont joined 06:42 domidumont joined 07:18 sivoais joined 07:28 sivoais joined 07:29 leont joined 08:33 ribasushi joined 09:14 domidumont joined 13:07 domidumont joined
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?
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, perlpilot joined
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
I can't figure out what shape of thing you're trying to propose here
I mean, I think we probably want to have configure and build and test and runtime requirements, ala CPAN::Meta::Spec 14:15
*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
and I really don't want 'only installs with panda' type things to happen again
ugexe right, im proposing the opposite of that
mst ok, then please elaborate 14:17
nine is just happy to see the discussion continue
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
if somebody else finds a more easily escapable corner than mine, I'm all for forgetting everything I've said ;)
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:19
what nine is doing can be built on top of that naturally, but it can be extended to be used for other parts 14:20
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
but it also lets those hooks have access to things like the current install status of other parts of the install chain 14:22
similar to nix
mst yeah 14:23
I like 14:25
and it also means that if a given implementation of the internals of said scripts turns out to be a terrible idea
we can discard it and move on
14:26 perlpilot joined
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:28
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:29
because of the 14:30
20:38 < mst> and suddenly a configure.pl6 that does
20:39 < mst> class MyBuilder extends Dsitribution::Builder with GitCloneRole {}
20:39 < mst> starts to seem rather easier :P
note
this could be a single script to begin with
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.
ugexe thats how zef implemented hooks long ago
mst hmmm
ugexe hooks/[pre/post]?-$phase.pl6
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
i.e. just lib/ and bin/
nine We don't need any build class at all for that
mst because CUR takes a tree of that format for install?
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:32
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.
mst right
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 github.com/hankache/Acme-Cow
mst nine: so how is that meta data read? does CUR just handle it internally?
nine mst: github.com/rakudo/rakudo/blob/nom/...on.pm#L119 14:35
mst aha
cool
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
oh, here's a thought 14:37
a basic Distribution::Builder that provides no-op configure() and build() stages, a standard test() and install() that are basically empty
ugexe install() probably doesnt fit in that though 14:38
mst well, maybe files-to-install() or something
to give the builder a chance to report things it compiled?
ugexe well so you can install to multiple CURIs or something 14:39
mst or maybe *it* is expected to return a Dsitrubition object
but I still think e.g. the MakeFromJSON should be shipped separately 14:40
rakudo can try and define an API
but I don't want any non-trivial implementations of it in core until they've lived in the outside world for a while
(and even then ... the saga of adding and then removing Module::Build in perl core was no fun for anybody) 14:41
nine: oh, also
my argument about a configure.pl6 above
it strikes me that we could support inc/MyBuilder.pm for that
which I think maybe works out nicely 14:43
with the understanding that people will need do with something like
with Distribution::Build::API<ver:1.0>
ort something 14:44
so we can upgrade the API the core thing provides later
nine: obviously, being able to -not- have a configure.pl6 is totally dependent on having lexical imports working :D
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 :)
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:50
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.
well now we're on the same page :)
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:52
mst right 14:53
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
which I *think* simplifies things?
14:55 domidumont joined 16:30 perlpilot joined 17:01 leont joined 17:10 lizmat joined 18:00 leont joined 18:47 domidumont joined 18:56 leont joined 19:43 perlpilot joined
[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:26
er, :) 20:27
mst 'a curl installer' ?
oh, right, I see 20:28
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
mst aaaaaaaaaaaaaaaaaaaaaaaaaa 20:41
[Coke] mst: calm. blue. ocean. 20:43
mst [Coke]: MY GOD IT'S FULL OF SHARKS
[Coke] mmhehehe.
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? ;)
mst I'm being positive over there
it'll be fine
[Coke] I ... trust you.
(pause only for dramatic effect. :)
mst trout.me.uk/areyousure.jpg 20:45
DrForr I had to explain this same problem in a different guise to my team last month. 20:46
mst DrForr: .oO 'eval $(curl -L thing | sh)' 20:48
what could possibly go wrong
DrForr "Hold my beer." 20:50
ugexe bbbbut windows curl alias doesn't work with -L! 21:57
C:\\Users\\Nick\\Documents\\GitHub>powershell curl -L xxx 21:58
Invoke-WebRequest : A parameter cannot be found that matches parameter name 'L'.
ugexe is always tryign to find the magic invocation that works on GNU, BSD, and Win32 for various cli tools 21:59
22:07 stmuk 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!