|
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 11 January 2016. |
|||
| ugexe | ah i see the backslash case is taken care of already :) | 00:18 | |
|
02:49
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 | ||
| ugexe | nine: have you considered putting more functionality into Distribution? For instance, if .content from s22 is implemented it allows CU::R to not have to worry about turning the relative paths of the meta into an absolute path, as they just feed the meta keys to .content and it returns the data for the file | 03:34 | |
| Then CU::R::FS and CU::R::I can save that to a repo (and some other CU::R might do something like upload/ftp it somewhere), and do whatever else it needs to do (precompile, etc) | |||
| gist.github.com/ugexe/8684abcc89aa2d03d009 this demonstrates that somewhat with a Distribution::Local and a Distribution::Tar | 03:35 | ||
|
05:08
llfourn joined
|
|||
| hoelzro | I wrote up my thoughts and experiences on distributing helper libraries with dists: hoelz.ro/blog/distributing-helper-l...l6-modules | 05:32 | |
|
05:51
llfourn joined
|
|||
| nine | hoelzro: your usage of $*VM.config<dll> is broken on Linux and BSD | 07:15 | |
| m: say say $*VM.config<dll> | 07:16 | ||
| camelia | rakudo-moar 0c4db8: OUTPUT«lib%s.soTrue» | ||
| nine | If you make sure that the library is generated into resources/libraries/ it's enough to do "is native(%?RESOURCES{'libraries/linenoise'})". NativeCall will find the library according to the platform's convenions. | 07:17 | |
| That is: it will look for resources/libraries/linenoise.dll on Windows, resources/libraries/linenoise.dylib on OS X and resources/libraries/liblinenoise.so on others. | 07:18 | ||
| Your META.info should just read "resources": ["libraries/linenoise"] as well | 07:19 | ||
|
07:24
FROGGS joined
|
|||
| nine | So I dare say your Native::Resources is obsolete already as you'd hoped. What's missing is better support for this in LibraryMake | 07:24 | |
|
10:10
leont joined
10:18
peter4 joined
11:20
TimToady joined
|
|||
| nine | About uninstall: it takes a Distribution object, leaving the question where this object is coming from. That could be $*REPO.resolve(CompUnit::DependencySpecification(:short-name<Inline::Perl5>, :ver(v0.1)).dist but that feels like a bit of a roundabout way. | 13:25 | |
| hoelzro | nine: I found out about panda's special treatment of resources/libraries yesterday when hunting for panda-specific behaviors | 13:51 | |
| I'll probably stick with using N::R until zef supports that, and maybe that behavior is spec'd | 13:52 | ||
| agreed about LibraryMake, though | |||
|
15:12
FROGGS joined
16:21
hankache joined
|
|||
| ugexe | zef could install Native::Resources yesterday, but i changed the resources code to the /libraries/(*.*?)/ $*VM.platform-name thing to work with Inline::Perl5 | 16:47 | |
| hoelzro | well, N::R's needs didn't last very long =/ | 16:49 | |
| it makes me uncomfortable that all this isn't spec'd, but I don't know if this kind of behavior is going to be a 6.c vs 6.d thing | 16:50 | ||
| ugexe | i still like the idea of Distribution providing an API to the meta file via .meta and access to the content via .content(<provides Module lib/ModuleName.pm6>) (or .content(<resources libraries libname>)), then FileSystem or Installable don't have to care where the content is coming from | 16:51 | |
| instead they are only concerned with where it is going | |||
| hoelzro | that makes sense | 16:55 | |
| nine | ugexe++ # resource fixes | 17:16 | |
| ugexe: with your Distribution proposal, what would a repository that stores everything into an SQL database look like? | 17:17 | ||
| ugexe | using pseudo code (perl6 with dbix::class representing the sql parts) something like gist.github.com/ugexe/abdd3f0b9e03d696ba0b | 17:44 | |
| nine: ^ | |||
|
18:20
leont joined
|
|||
| nine | ugexe: ah, so you _do_ intend repositories to define their own Distribution subclasses | 18:32 | |
| ugexe | nine: s22 made it seem that way (saying Distribution is for CU::R::Installable), but the .content implementation should be usable by most CompUnit::Repository (im failing to think of an example ::Repository that wouldnt work) | 18:41 | |
|
19:00
FROGGS joined
19:23
leont joined
|
|||
| tony-o | i think it would work that way ideally | 19:29 | |
|
19:29
Kassandry joined
|
|||
| tony-o | since hte repo is really describing the storage mechanism, | 19:29 | |
| nine | ugexe: I think I'm misunderstanding something there. Do you mean that the Distribution classes can share the .content method? That doesn't seem likely as your own gist show two very different implementations. So I guess you mean something else? | 19:34 | |
| ugexe | Distribution is just an interface requiring a .meta and .content(*@keys) method. How each type of Distribution retrieves the data with .content is not important to the CompUnit::Repository, it just needs to know how to use that interface to get at the actual data | 19:36 | |
| tony-o | s/repo/distro/ | 19:38 | |
| nine | Ah, now I got it :) | 19:42 | |
|
20:51
FROGGS joined
|
|||
| sjn | \\o | 21:30 | |
| nine: ping | 22:16 | ||
| ugexe | zef can `--dry install Module::With::DepenenciesToGet` once again | 22:19 | |
| tony-o | ++ | 22:46 | |