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 11 May 2016.
01: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:34 domidumont joined 07:40 domidumont joined 08:31 domidumont joined 09:00 domidumont joined 12:14 domidumont joined 12:15 domidumont joined 13:32 jdv79 joined
nine ugexe: I think handling '*' versions by always upgrading is the only sane option. 17:03
ugexe: well the other one would be to prohibit '*' as a version
Which I could live quite well with. I'm not aware of any other system that would allow a whatever version and I have no idea for a use case. When I don't really have a version yet, I just use 0.1 or 0.0.1 17:04
rev-deps are still an open issue anyway. The rev-deps files are still written to by PrecompilationRepository instead of the PrecompilationStore and we only look at rev-deps in the same repo as we install to. 17:06
I've pondered removing the rev-deps handling alltogether but install time is the only time we know we can write to a repo, so we should use the chance to update precomp files of site/vendor and perl 17:07
ugexe rev-deps still needs non-Precompilation related access though, as this is intended for removing the source files
nine You can always find them via .installed and reading the meta info 17:08
ugexe right. but i would hope that this could be made so you can easily write a 1 liner to install or uninstall a module (if it has no dependencies) 17:09
i generate the revdeps list exactly how you mention, but it just seems it would be useful internally as well 17:10
nine definitely 17:11