Perl 6 - the future is here, just unevenly distributed

IRC log for #perl6-toolchain, 2017-05-11

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

All times shown according to UTC.

Time Nick Message
01:51 ilbot3 joined #perl6-toolchain
01:51 Topic for #perl6-toolchain is now Fire is step THREE! | https://github.com/perl6/toolchain-bikeshed | Channel logs: http://irclog.perlgeek.de/perl6-toolchain/today | useful prior art: https://metacpan.org/pod/CPAN::Meta::Spec
05:30 sivoais joined #perl6-toolchain
05:31 sivoais joined #perl6-toolchain
05:46 domidumont joined #perl6-toolchain
05:52 domidumont joined #perl6-toolchain
07:06 lizmat joined #perl6-toolchain
12:18 nine There may be multiple environments active at the same time. Python package names will differ on openSUSE and Debian for example but on both systems pip may be available.
12:19 nine Also users will have different preferences regarding installation sources
12:26 nine One way of installing may require root privileges which may or may not be available while another way may not
12:26 * sjn has ha "favorite" dependency hell... native dependencies that change name between upgrades
12:40 nine There's another one: changing version systems in a way that breaks the sort order
12:49 sjn hah! yeah, that's a nice one
13:12 nine Actually Inline::Perl5 is a pretty interesting use case. It depends on libperrl.so but you won't find that in the standard location
13:47 nine puppet can also be a source for inspiration. It's mostly declarative and it solves quite similar problems.
13:49 nine Now that I think of it, wouldn't it be nice to be able to declare, that your tests need a running PostgreSQL database? Maybe with a user to access it?
13:49 * nine goes on to reinvent configuration management...
13:59 nine New plan: I'm just going to throw horribly naive ideas about this at the wall until someone with an actual clue can't bear it anymore and starts implementing something useful.
14:26 lizmat joined #perl6-toolchain
14:28 sjn nine: yes, I agree. "Native dependencies" and other types of resource dependencies aren't really that hard to do...
15:18 nine The platform itself can really just be another dependency. If your module depends on Linux, there's no point in trying to install it on Windows. The installer can take this info to decide between ORed dependencies.
15:50 stmuk joined #perl6-toolchain
15:51 sjn yeah, same goes for other resources. "my application needs an unused port 80"
16:04 lizmat please note that you probably would *not* want it to try to install the dependency, but it should just die
16:20 domidumont joined #perl6-toolchain
16:30 domidumont1 joined #perl6-toolchain
16:50 domidumont joined #perl6-toolchain
16:57 sjn lizmat: actually, that decision should probably be deferred to the program that does the actual installing
16:58 sjn if it is in a position to resolve a dependency, then why not let it?
17:00 sjn (with that said, if the installer in question is part of the perl6 toolchain, then yes, it may be best to not install something if it can't do it properly.)
17:13 jdv79 hows the conf going?
21:33 stmuk_ joined #perl6-toolchain
22:52 lizmat joined #perl6-toolchain
23:32 lizmat_ joined #perl6-toolchain
23:35 stmuk joined #perl6-toolchain

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