Closed codesections closed 2 years ago
It won’t help unless the versions being used are pinned — the same issue would just reveal itself after installation instead of before.
Actually I also expect the repos zef sets for testing to already be in front of existing repositories… I wonder if it’s specific to using the rakulib env instead of e.g. -I
$ RAKULIB=foo raku -Ibar -e '.say for $*REPO.repo-chain'
file#/Users/ugexe/bar
file#/Users/ugexe/foo
inst#/Users/ugexe/.raku
inst#/Users/ugexe/.rakubrew/versions/moar-2022.07/install/share/perl6/site
inst#/Users/ugexe/.rakubrew/versions/moar-2022.07/install/share/perl6/vendor
inst#/Users/ugexe/.rakubrew/versions/moar-2022.07/install/share/perl6/core
ap#
nqp#
perl5#
It does seem like the test libs (zef uses -I /path/to/repo
) should actually be in front, hmmm
Ah, JSON::Fast
uses use lib "lib"
in its tests, something that shouldn't be done. I would wager that is the cause
Ah, that explains it. Thanks for looking into it!
When running a command such as
zef install Foo:ver<0.2>
, zef runsFoo
's tests. However, if the current repo-chain contains aFoo:ver<0.1>
in an earlier Repository than the oneFoo:ver<0.2>
is being installed to, then Raku's normal rules for dependency resolution result inuse Foo;
being resolved to v0.1, not v0.2. This is very likely to causeFoo:ver<0.2>
's tests to fail.Could Zef avoid this problem by somehow forcing the target repo to the front of the repo chain during testing?
Here's a reproducible example: