Perl 6 - the future is here, just unevenly distributed

IRC log for #perl6-toolchain, 2017-03-04

| Channels | #perl6-toolchain index | Today | | Search | Google Search | Plain-Text | summary

All times shown according to UTC.

Time Nick Message
08:30 llfourn joined #perl6-toolchain
09:06 FROGGS joined #perl6-toolchain
10:37 llfourn joined #perl6-toolchain
10:57 domidumont joined #perl6-toolchain
11:04 domidumont joined #perl6-toolchain
13:59 domidumont joined #perl6-toolchain
14:22 DrForr joined #perl6-toolchain
14:31 llfourn joined #perl6-toolchain
15:49 llfourn joined #perl6-toolchain
16:50 llfourn joined #perl6-toolchain
17:49 llfourn joined #perl6-toolchain
18:50 llfourn joined #perl6-toolchain
19:52 llfourn joined #perl6-toolchain
20:38 sjn ugexe: hey, do you accept new features to zef? :)
20:55 llfourn joined #perl6-toolchain
21:36 ugexe sjn: Sure. But you'd probably want to point out what you want to do before implementing anything
21:56 llfourn joined #perl6-toolchain
22:00 sjn ugexe: I've been thinking about ways to specify other dependencies than just regular modules
22:00 sjn e.g. "/usr/bin/dot", which perl6-doc depends on, but isn't listed
22:02 sjn well. right now, there's no way to specify those kind of deps at all
22:04 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?
22:04 sjn yeah, that's exactly what i *don't* want to do
22:05 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
22:06 sjn first of all, I'd like to allow a new syntax in META6.json's dependency fields
22:08 sjn 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:09 ugexe right, you want to Build.pm `use Some::Helper; build-deps()`
22:09 ugexe but incouding Some::Helper with zef and panda.
22:10 ugexe im more interested in a solution that is generic enough to go in CURI, which I believe has been discussed in here before
22:13 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:15 sjn meaning, making that part of zef work like something similar to Test::Harness
22:16 sjn ugexe: does that make any sense to you? :)
22:18 ugexe yes, https://github.com/ugexe/zef/blob/master/lib/Zef/Build.pm6 allows such theoretical plugins, and it does so in practice with Build.pm
22:19 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:20 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
22:21 sjn the reason for that, is that *strictly* speaking, these dependencies (and their resolution) really don't *have* to be filesystem-related
22:22 sjn decoupling how it's done from how we specify what needs to be done would allow us to do some really useful stuff
22:23 sjn @binary(/usr/bin/dot) would be only a first step
22:23 sjn @library(libxml2.so.1) might me another one
22:25 sjn or one might make it easy to handle dependencies that a full application stack implemented in Perl6 might require
22:25 sjn e.g. @available-port(80)
22:26 sjn or even @available-storage(10Gb)
22:28 sjn 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:29 * sjn has wanted something like this for Perl 5 for *years*
22:40 ugexe you can do this now with a custom CUR/Distribution pair
22:40 ugexe the decoupling ^
22:41 ugexe im not sure what logic you would want in each one, but thats one way to think of a solution
22:43 ugexe 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:46 nine One would want information about external dependencies to be purely declarative so it can be automatically translated into e.g. .spec files.
22:47 sjn nine: exactly
22:58 llfourn joined #perl6-toolchain
23:03 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 nine And Perl 5 people have talked about this for like ever.
23:05 nine 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:06 nine 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:46 llfourn joined #perl6-toolchain

| Channels | #perl6-toolchain index | Today | | Search | Google Search | Plain-Text | summary