|
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 10 May 2017. |
|||
|
01:51
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 | ||
|
05:30
sivoais joined
05:31
sivoais joined
05:46
domidumont joined
05:52
domidumont joined
07:06
lizmat joined
|
|||
| 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:18 | |
| Also users will have different preferences regarding installation sources | 12:19 | ||
| 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 | |||
| nine | There's another one: changing version systems in a way that breaks the sort order | 12:40 | |
| sjn | hah! yeah, that's a nice one | 12:49 | |
| 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:12 | |
| puppet can also be a source for inspiration. It's mostly declarative and it solves quite similar problems. | 13:47 | ||
| 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... | |||
| 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. | 13:59 | ||
|
14:26
lizmat joined
|
|||
| sjn | nine: yes, I agree. "Native dependencies" and other types of resource dependencies aren't really that hard to do... | 14:28 | |
| 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:18 | |
|
15:50
stmuk joined
|
|||
| sjn | yeah, same goes for other resources. "my application needs an unused port 80" | 15:51 | |
| lizmat | please note that you probably would *not* want it to try to install the dependency, but it should just die | 16:04 | |
|
16:20
domidumont joined
16:30
domidumont1 joined
16:50
domidumont joined
|
|||
| sjn | lizmat: actually, that decision should probably be deferred to the program that does the actual installing | 16:57 | |
| if it is in a position to resolve a dependency, then why not let it? | 16:58 | ||
| (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:00 | ||
| jdv79 | hows the conf going? | 17:13 | |
|
21:33
stmuk_ joined
22:52
lizmat joined
23:32
lizmat_ joined
23:35
stmuk joined
|
|||