🦋 Welcome to the MAIN() IRC channel of the Raku Programming Language (raku.org). This channel is logged for the purpose of keeping a history about its development | evalbot usage: 'm: say 3;' or /msg camelia m: ... | Log inspection is getting closer to beta. If you're a beginner, you can also check out the #raku-beginner channel!
Set by lizmat on 25 August 2021.
spacekookie So I'm looking at RAKULIB as a search path and I'm wondering if there's a way to make rakudo look for module more recursively. i.e. I point it at something like lib/perl6/site_perl (similarly to perl5) in which are then different raku distributions 09:52
Not 100% sure how this is supposed to work from the raku modules docs 09:53
Or should I just set RAKULIB manually to include all paths to modules that a package requires? 09:56
lizmat spacekookie: feels like you want to create your own REPO logic? 10:46
spacekookie Is a REPO in Raku something special? 10:48
gfldex m: say $*REPO; 10:49
camelia inst#/home/camelia/.raku
lizmat when you want to load a module in Raku, it's basically asking whatever is in $*REPO if it knows about a given module
if it does, then you'll be able to load it
lizmat through the $*REPO logic 10:50
in fact $*REPO is a chain of repo's
if the first doesn't know about it, it can ask the second, etc.
Raku comes standard with the "Installed modules" repo
and the "filesystem modules" repo 10:51
(and a few other ones, but that's not important right now)
the "installed modules" only knows about modules that you have installed with e.g. "zef install Foo::Bar"
the "filesystem" one only knows about modules as files in a directory 10:52
(which is much like Perl treats modules)
when you say "use lib 'foo/bar'"
you are in fact inserting a REPO at the front of the chain, that will look for modules in the "foo/bar" directory 10:53
spacekookie: are you still with me?
spacekookie Yea, that makes sense 10:54
The background to what I'm trying to build is that on NixOS there's no such thing as an "installed module". Each program has access to the modules it needs, but they are install at some path in /nix/store 10:55
So for any given program we wrap it in a script that sets RAKULIB to a path on where to find its dependencies 10:56
lizmat and "use lib" is not cutting it for you?
spacekookie But thinking about this for a bit longer, actually it makes total sense to have RAKULIB be a comma separated path for each of the dependencies
"use lib" has to look for the module somewhere though, right? Which is determined by the search path?
Or is it the filesystem one?
lizmat use lib is the filesystem one 10:57
spacekookie Ah
lizmat it has the disadvantage that it does **NOT** know about versions
spacekookie That works fine for includes _inside_ a module but to bundle an program together it's a bit inconvenient
lizmat so if you do "use foo:auth<lizmat>:ver<0.0.2>" and the use lib repo finds a "foo.rakumod", it will use that *without* checking version or auth matching 10:58
spacekookie Interesting 11:00
Anyway, I think I have a decent solution for this now (if you're interested: dev.spacekookie.de/kookie/nomicon/...lt.nix#L17 -- currently in my own fork, but it'll be upstreamed soon(tm))
lizmat ugexe tonyo El_Che might be better suited to judge that 11:02
they're more into packaging / module installations than I am
spacekookie So the general structure of a raku package is then $out/{bin,/lib/perl6/site_perl} with the latter containing the code shipped by the module. And the RAKULIB path is a set of $out/lib/perl6/site_perl and links to every other dependency that's required (and packaged at their own /nix/store/whatever/ paths
Well, thanks for your help anyway :)
lizmat yw
spacekookie fwiw it's also the first build support system I try to build for nixpkgs x) 11:03
lizmat ah, an opportunity for double learning :-) 11:06
ugexe use lib will know about versions if it points to a repo that knows about versions 12:26
something like `use lib "lib"` might not similarly to `-I lib`, but thats why people should be using `use lib "."` or `-I .` (i.e. pointing at the base directory of the distribution where the META6.json resides, not its lib/ subdir) 12:28
lizmat spacekookie ^^ 12:29
ugexe++ # reminding me about META6.json being used if found by use "lib" 12:30
ugexe i wrote github.com/ugexe/Perl6-CompUnit--R...itory--Lib years ago to do a recursive lib/ type structure like github.com/ugexe/Perl6-CompUnit--R.../test-libs 12:34
but thats a prototype
spacekookie Hmm, why are there two separate keys in the p6c.json to get the repository url (support.source and source-url)? Are there semantic differences between them? 15:34
moritz_ I think one is new style, one is old style, and we never finished the transition, or something 15:43
spacekookie Okay so I guess I'll start sending out some PRs x) 15:45
raydiak I'm not entirely sure that one is meant to be deprecated. META6, which we link to from the docs on META files, uses both. zef uses only support.source in its META6.json but happily works with either one afaik. fez uses only source-url in it's META, not sure what it looks at when running. our docs have no mention of "support". S22 has no mention of "source-url". 16:07
since we have no spec for meta files and don't consider either the docs or syns or anything else authoratative, it's just "whatever the prevailing tooling wants" 16:08
ugexe source-url is more something defined by ecosystems. id say support.source is for humans to enter and source-url is more something that should be generated (even though that isnt the case for p6c) 16:12
if zef was uploaded to cpan then its source-url would be a url to its cpan .tar.gz regardless of what its value was when it was uploaded, but the support.source would still point to whatever its value was (in this case the git repository) 16:17
spacekookie Hmm, okay. Is there a reason to actually have this be two fields? i.e. why not just use the "human" value for everything? 16:37
ugexe who says you know what the value is before uploading? 16:46
something like our cpan usage is going to overwrite source-url with the appropriate .tar.gz url which is generated. if we only use one of these values then there is no longer an linkage to the source 16:47
spacekookie Hm, fair enough. I guess some modules are also just hosted on modules.raku.org and don't have a repo of their own somewhere? 16:48
ugexe they dont have to have a repo, no 16:59
japhb xinming: Missed your discussion yesterday, but not that the CBOR format is designed to be extensible for exactly things like Captures that you want to be able to roundtrip and can be described semantically, but may only be "native" in some languages. CBOR::Simple (which I wrote) supports this conceptually, but I have not yet added Capture as an explicit extension. 21:42
xinming: Anything I should know about your use case that would imply something more advanced than "2-tuple of positional and associative tagged to roundtrip as a Capture object"? 21:43
*but note that 21:44
(I suspect that a similar concept is needed by Lua for tables, but I'm not a Lua expert)
Oh, I should also note that CBOR::Simple is *way* faster than .raku/EVAL for any data structure it supports. 21:46
(see github.com/japhb/serializer-perf for more details)
raydiak Lua tables don't really distinguish between named and positional, it's all just a key lookup and positional is syntactic sugar. like our object hash, keys can be numbers or strings or whatever. as far as Lua functions go, there's no named params, you pass a table if you want to do that (at least in 5.1, when I learned it...don't think that's changed though) 22:49
not very relevant, just FYI :) 22:50
though now that I think about it like that...does CBOR::Simple support object hashes? you could theoretically just stuff the positional params into Int keys and the named into Str keys all in one hash. might be more compact. not sure about performance 22:55
or maybe not more compact since you'd have to store the type of each key. idk, was just a thought 23:01

Powered by Cro and the Raku® Programming Language.

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

Thank you!