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 19 March 2016.
01:07 lizmat joined 02: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
07:00 domidumont joined 07:05 domidumont joined 07:55 TimToady joined 08:22 FROGGS joined 12:10 perlpilot_ joined 14:10 cognominal joined 14:18 mst joined 14:20 sjn joined 15:07 MadcapJake joined
domidumont Hi. I've created on Debian a perl6-panda package that contains /usr/share/perl6/Shell/Command.pm. But the perl6 -MShell::Command -e'say "hello"' cannot find the command. See paste.debian.net/418379/ 15:17
Tweaking PERL6LIB env variable enables perl6 to find the module.
What did I miss ?
I mean, why perl6 is not able to load the module, even thought the error message is listing the directory where Shell::Command is installed ? 15:20
lizmat domidumont: no idea, maybe nine has one ? 15:22
nine Can I have a look at the contents of this package? 15:27
domidumont nine: paste.debian.net/418383/ lists the content of the package 15:29
nine /usr/share/perl6 is under control of a CompUnit::Repository::Installation. That expects a very special directory layout which you almost cannot get right manually. 15:31
Have a look at page 25 and following: niner.name/talks/A%20look%20behind%...rl%206.pdf 15:32
That should give you a good idea on what's going on and why trying to package modules is really hard right now.
domidumont I see. This is waaaayyyy more complication than I expected. Thanks for the info. I guess that I've no choice but to wait for packaging tools dedicated to distro packaging to be ready... 15:56
16:38 sufrostico joined
ugexe `zef --to"inst#some/location" install XXX` works, but you have to use `-Iinst#some/location` for anything that uses it or add it to PERL6LIB 16:55
CURI will create the appropriate directory structure
17:13 Kassandry joined 18:00 domidumont joined 19:15 camelia joined
ugexe nine: can stuff like !sources-dir, !bin-dir() be moved to CompUnit::Repository::Locally? then that role could also be applied to an implementation of Distribution to absolutify an IO::Handle for CURI based storage (i.e. round trip Distribution from installed, or install a Distribution from one ::Installable to another without losing any original meta data) 19:41
nine Repository::FileSystem also does ::Locally 19:46
That wouldn't fit very well
ugexe yeah, but it can be optional 19:47
it'd get called $xxx.?something ($xxx.?absolutify() seems to have wanted to serve a similar purpose)
im not saying thats the right solution, but that piece seems to be common enough to warrant some type of ability to share that info 19:48
its also meant specifically for ::Installable CUR 19:50
so maybe an :Installable specific role
nine Why not just create a new role? Maybe one that's lexically scoped to Repository::Installation? 19:51
19:52 FROGGS joined
ugexe and apply it to CURI? 19:53
or initialize the role's members in CURI?
nine I'd probably apply it 19:55
ugexe im getting the hunch that ::FileSystem can be split up between CUR::Locally and Distribution::Local::Directory/FileSystem 20:52
there is some disambiguity between ::Installation ::FileSystem and ::AbsolutePath in relations to Distributions i cant put my finger on, but i think thats where this is going 20:54