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 15 August 2017.
01:52 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
06:18 domidumont joined 06:25 domidumont joined
nine ugexe: what would we have to do to create the rest of the %!meta? 07:09
10:08 llfourn joined 14:06 domidumont joined
ugexe we want to fill out defaults - name (probably $!prefix or $.path-spec), ver/api (0), perl (6.*) - and generate provides/files. to generate provides/files it has to make assumptions: that if $!prefix/../resources or $!prefix/../bin exist that they belong to the distribution and should have DIR-RECURSE called on them (from which we can generate provides/files) 14:55
we already make this assumption for resources/ 14:56
for -Ilib to use %?RESOURCES
the alternative, as I have also mentioned, is taking %?RESOURCES from -Ilib and quit treating this as a distribution 14:57
but I think by creating the entire distribution meta its ok to do the ../ thing, because the info to see what was actually used is now available in the CompUnit.distribution 14:58
nine This will cost a bit of performance though 15:04
ugexe for what? 15:05
nine recoursing into additional directories
ugexe well we already recurse the "lib" to get the CURFS id. technically we should recurse "resources" too since its being used. so its really only additionally recursing bin/ 15:06
nine I don't think we have to recurse into "resources" as those will be loaded at runtime, won't they? 15:07
ugexe yeah I suppose I'm not sure about technically afterall. however - this would appear to be the case for -I. already 15:09
nine Oh, also we only consider .pm and .pm6 files anyway 15:10
github.com/rakudo/rakudo/blob/nom/...tem.pm#L66 15:11
ugexe right, but only for slurping. the same amount of looking still happens
heh also it should check .pm6 first now, since that will be chosen over .pm 15:12
if the penalty is too high we can always do meta lazily like in the .candidates PR 15:15
with a .candidates in CURFS and CURI though it makes writing plugin systems much easier 15:17
i really wouldnt be against changing .installed to .available, and then giving that method to CURFS as well 15:19
nine We could also keep .installed and have it forward to .available. 15:21
ugexe yeah. i wouldnt mind .installed in CURFS either... but something does feel off about it 15:22
BUT im also not against CURFS having a .install either, that essentially just does a cp into a sha1 directory 15:24
nine What would be the use case?
ugexe when you -just have to- keep all the original file naming stuff or something. 15:26
nine But why would you? :)
ugexe some plugin local lib type thing that retains original paths so its still human navigatable
the only reason I know of we need to fix in CURI anyway - DLL names 15:27
nine For that Punycode will be the proper solution.
ugexe yeah. however, I would ask what is the big drawback? the method itself should just be a `copy $dir1 $dir2` 15:29
nine I very much prefer designing APIs where I know the use cases they are meant for. APIs tend to become much more useful that way. Especially in software where we have to support such APIs for a very long time. 15:30
ugexe fwiw these api proposals are all implementations in zef already 15:31
you could then easily (nearly) round-trip back distributions doing things like $my-curfs.install($curi.need("Zef").distribution) 15:33
nine While in this case the interface is actually already designed, the semantics are not. E.g. what happens with the META data? What happens if a META6.json file is already there? Same for module files. 15:36
15:36 lizmat joined
ugexe I do not understand. These are all problems that already exist 15:37
nine But CURFS doesn't have an .install method yet? 15:38
ugexe install takes a Distribution, so it would have all neccesary data
if the directory isn't empty, then yes this would be foolish. dont install (like git wont clone into non-empty dir) or let them be foolish 15:39
this is why i liked the name .store better 15:40
that type of decision already has a place though - method can-install() { } 16:19
method can-install() { (!$!prefix.e && $!prefix.mkdir) || ($!prefix.w && !Rakudo::Internals.DIR-RECURSE($!prefix).elems) } for example 16:20
hmmm, a bug report just revealed an issue with CUR:RR.run-script - it doesn't work if you have non-perl6 scripts in your bin/ 17:05
nine But did that work before? 17:30
ugexe ah right, it still used $*EXECUTABLE so it must have never worked 17:38
nine Also it's kinda sad that people ship non-perl6 scripts considering how lovely Perl 6 is for writing CLI programs... 17:40
ugexe (try require "$bin") || shell($bin); # theres always the 'fuck it' way 17:47
nine Well "it" in that case is "debugging" :) 17:55
ugexe its more "how do you guess if bin/foo is a perl6 script or not" 17:56
mst check the #! line would seem like a good answer 17:58
ugexe right, need heuristics for when people use .pl6 and whatnot as well 17:59
nine If we want to support that 18:00
ugexe if it can be handled by 2 lines of code checking just the extension and shebang, i think its reasonable to support it. but ive no idea if thats good enough or not 18:31
rt.perl.org/Public/Bug/Display.html?id=131911 18:36
as for why to support it, I would guess its because they havent considered how to do what they want with %?RESOURCES (assuming what they want is to provide bin scripts to be used as tools for their dist and not neccesarily make them invokable by name) 18:45
e.g. run( %?RESOURCES<scripts/perl5tar.pl> ) 18:49
nine I have the nagging feeling that this looks deceptively simple. It is a heuristic, so it will be wrong in some odd cases. 18:51
ugexe what if we make it required to declare bin scripts... is there some info they could also be required to add that solves this?
or rather, required if you dont want it to blow up like this 18:53
nine Having a separate directory for arbitrary scripts or requiring some META info sounds much more sustainable. 18:54
Of course non-Perl 6 scripts won't support installation of multiple versions
ugexe why not? the scripts get installed individually due to name hashing, so I would think the wrapper just needs to know if it should launch require $some-path or shell $some-path 18:56
nine Oh, of course, if we still have a Perl 6 wrapper, then we're fine 18:57
ugexe right, the name of the wrapper would be disingenuous for them if they have a file extension, but it should still work 18:59
now, how does windows fuck this up 19:00
19:33 ZofBot joined 20:14 awwaiid joined 23:47 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!