|
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 18 February 2016. |
|||
|
02:27
stmuk_ joined
02:48
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 | ||
|
07:17
MadcapJake joined
07:22
FROGGS joined
09:31
lizmat joined
|
|||
| El_Che | hallo. I have experimenting on how to get perl6 into production, among these docker. I base my image on rakudo star because it has a frozen state. I am looking in the rakudo star tar to find out panda installs the supplied modules. For developments like docker it would be great to have a configure parameter to cherry pick the modules to be installed instead of the complete star distribution => smaller image. This would probably wo | 09:51 | |
| do I make sense? | |||
| of course starting from rakudo proper would be an option, but the frozen state of modules is the biggest attraction for R* in this context | 09:53 | ||
| nine | El_Che: why exactly is it important that the bundled modules are in a frozen state? | 10:37 | |
| El_Che | the image must generate something reproducible each time. You don't want a random module changing it's api or failing | 11:05 | |
| .precomp is biting me today. Installed new version of (my) module and still getting the old module. Removed the .perl6 dir for the user running the app and for root (that installed the module) | 11:07 | ||
| weird | |||
| nine | If you need fixed versions of modules, use fixed versions that work for you. R* contains arbitrary fixed versions that have nothing to do with your applications. We do have proper version support in Perl 6 to solve this problem. | 11:26 | |
| El_Che | I am thinking on how easily dockerize a random perl6 app. Assuming the rakudo star module freeze -although- random seem to be the only way to get a stable base. It may be random, but those version will be more tested probably | 11:31 | |
| nine | No they aren't more tested. Your random perl6 app really should declare exact versions of all its dependencies. | 11:40 | |
| El_Che | yes, but I am thinking more generic. Not my app, but a random user app. I want that the author can dockerize his app with the least trouble as possible. The freezing mindset is mine view on a good docker setup and not related to the app itself | 11:49 | |
| just trying some things out to have a generic solution for releasable perl6 code | 11:50 | ||
| not a lot people will be happy to compile perl6 and ecosystem to prepare a deployment. Deploying a docker blob sounds like a good alternative in these early days | 11:51 | ||
| imho | |||
| so nine, no chance that rakudo star modules version will evolve to a kind of "approved stable version" in a far future? | 11:55 | ||
| if that's not the case, your suggestion is valid: let the module declare it's dependencies | 11:57 | ||
| nine | I actually think we should abandon rakudo star in favor of proper version support and a development culture that nails down versions and/or API stability. | ||
| El_Che | that makes sense to me | 11:58 | |
| a lot of sense | |||
| I fear that if perl6 takes off, we may end otherwise in a ruby mindset were everyone lives in constant fear to update their gems | 11:59 | ||
| (for the few ruby programs I have (mostly puppet related), I clone gems version to my application repo and update pretty carefully) | 12:00 | ||
|
12:51
sufrostico joined
|
|||
| perlpilot | nine++ Having that exact discussion about module versions for apps at work. | 14:04 | |
| nine | The irony is that at work we're still using system perl and installing modules directly from CPAN and that it mostly works just fine. But I could sleep better if we had proper processes for upgrading modules. | 14:09 | |
| perlpilot | yep. If the perl community already had that culture of nailing down versions, we wouldn't be struggling with how to install our apps with all the proper versions (and only those versions). And the path to upgrading those modules would be more straight forward. And each dev team using Perl in the world wouldn't have to re-discover how to do these things and which tools to use. | 14:16 | |
|
14:24
perlpilot joined
|
|||
| El_Che | the thing is, perl5 is mature, perl6 isn't: paradoxically version pinning is more important | 14:34 | |
| ugexe | unparadoxically it means its more important to get right | 15:03 | |
| El_Che | an unparadoxical paradox is a paradoxical definition of a paradox | 15:07 | |
| :) | |||
|
15:59
autarch1 joined
16:20
Cheery joined
17:37
cognominal_ joined
18:05
sufrostico joined
18:18
cognominal joined,
b2gills joined
18:25
mst joined
18:27
ranguard joined,
llfourn joined
19:00
Kassandry joined
19:35
sufrosti1o joined
|
|||