|
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 2 March 2017. |
|||
|
08:30
llfourn joined
09:06
FROGGS joined
10:37
llfourn joined
10:57
domidumont joined
11:04
domidumont joined
13:59
domidumont joined
14:22
DrForr joined
14:31
llfourn joined
15:49
llfourn joined
16:50
llfourn joined
17:49
llfourn joined
18:50
llfourn joined
19:52
llfourn joined
|
|||
| sjn | ugexe: hey, do you accept new features to zef? :) | 20:38 | |
|
20:55
llfourn joined
|
|||
| ugexe | sjn: Sure. But you'd probably want to point out what you want to do before implementing anything | 21:36 | |
|
21:56
llfourn joined
|
|||
| sjn | ugexe: I've been thinking about ways to specify other dependencies than just regular modules | 22:00 | |
| e.g. "/usr/bin/dot", which perl6-doc depends on, but isn't listed | |||
| well. right now, there's no way to specify those kind of deps at all | 22:02 | ||
| ugexe | fwiw it can be done now. in meta6.json just create your own field `x-external-deps`, and then in Build.pm - `class Build { method build($dir) { die unless run "which", "$_" for $dir.child("META6.json").slurp.&from-json<x-external-deps> } }` | 22:04 | |
| sjn | ugexe: have you thought about those kind of issues in some way? | ||
| yeah, that's exactly what i *don't* want to do | |||
| ugexe | right, you want to Build.pm `use Some::Helper; build-deps()`, but that was verbose for brevity | 22:05 | |
| sjn | having to write custom build code for something as pedestrian as depending on a binary seems just... *wrong* to me | ||
| first of all, I'd like to allow a new syntax in META6.json's dependency fields | 22:06 | ||
| and have zef/panda allow those, and 1) just give a meaningful warning when they're seen, and 2) open up for system/OS/etc. dependent code to be able to handle those, and finally 3) offer that this information to downstream packagers in a sane way so that they can build their packages with correct dependencies on their side, without having to do lots of manual tweaking | 22:08 | ||
| ugexe | right, you want to Build.pm `use Some::Helper; build-deps()` | 22:09 | |
| but incouding Some::Helper with zef and panda. | |||
| im more interested in a solution that is generic enough to go in CURI, which I believe has been discussed in here before | 22:10 | ||
| sjn | well, I would say the *smart* thing would be to shell out that part of the build process to a specific executable, and then allow different OS packagers to just implement that in any way they need (minus any required input/output that we need in order to track progress/success/failure) | 22:13 | |
| meaning, making that part of zef work like something similar to Test::Harness | 22:15 | ||
| ugexe: does that make any sense to you? :) | 22:16 | ||
| ugexe | yes, github.com/ugexe/zef/blob/master/l.../Build.pm6 allows such theoretical plugins, and it does so in practice with Build.pm | 22:18 | |
| sjn | the thing is, I think it's a mistake to put OS/package-manager/file-system/etc. specific code in CU::R::I | 22:19 | |
| ugexe | CURI purpose is pretty much file-system | 22:20 | |
| sjn | I thing it would be a lot more sensible to specify some kind of TAP-like protocol for this instead, and then let each OS packager/vendor implement as they see fit | ||
| the reason for that, is that *strictly* speaking, these dependencies (and their resolution) really don't *have* to be filesystem-related | 22:21 | ||
| decoupling how it's done from how we specify what needs to be done would allow us to do some really useful stuff | 22:22 | ||
| @binary(/usr/bin/dot) would be only a first step | 22:23 | ||
| @library(libxml2.so.1) might me another one | |||
| or one might make it easy to handle dependencies that a full application stack implemented in Perl6 might require | 22:25 | ||
| e.g. @available-port(80) | |||
| or even @available-storage(10Gb) | 22:26 | ||
| thinking with a TAP-like protocol (e.g. Install Anything Protocol?), we would just have to specify what's allowed, and then leave space for OS vendors (or packagers) to implement the bits that do what's necessary and then report back with info about status/success/failure/progress/etc. | 22:28 | ||
| sjn has wanted something like this for Perl 5 for *years* | 22:29 | ||
| ugexe | you can do this now with a custom CUR/Distribution pair | 22:40 | |
| the decoupling ^ | |||
| im not sure what logic you would want in each one, but thats one way to think of a solution | 22:41 | ||
| something like that could be installed to rakudo so you can still install modules from the command line without explicitly using any modules (although implicitly loading your installed CUR) | 22:43 | ||
| nine | One would want information about external dependencies to be purely declarative so it can be automatically translated into e.g. .spec files. | 22:46 | |
| sjn | nine: exactly | 22:47 | |
|
22:58
llfourn joined
|
|||
| nine | This whole thing feels like an issue that's just waiting for someone to implement _something_. Even if it gets stuck at 80 % that's 80 % more than all the speculation over the years has brought ;) | 23:03 | |
| And Perl 5 people have talked about this for like ever. | |||
| Taken far enough, even Perl 6 dependencies would fall into the same category. Which would give distributors hooks to handle even Perl 6 dependencies. | 23:05 | ||
| I.e. even if Foo::Bar is not available as a native package for my distro, Foo::Bar's dependencies may be available. But as a user I can only either find out what those deps are and install them manually or bite the bullet and wait for cpan/zef to install them. | 23:06 | ||
|
23:46
llfourn joined
|
|||