Closed bcardiff closed 4 years ago
I implemented a more conservative update.
One case that I am not sure is:
metadata = {dependencies: {awesome: {git: git_url(:forked_awesome), branch: "feature/super"}}}
lock = {awesome: "0.1.0", d: "0.1.0"}
with_shard(metadata, lock) do
assert_locked "awesome", "0.1.0", source: {git: git_url(:awesome)}
output = run "shards install --no-color"
end
The feature/super
branch has the 0.1.0 release as ancestor, so it's rechable and the install can be conservative. The final lock in the above example still points to 0.1.0. If update is done the branch is used, but not in the install.
Is that the right thing to do?
@bcardiff I think that's actually independent of this PR and dependency source changes. There is in fact a TODO
in the git resolver for that 😉
https://github.com/crystal-lang/shards/blob/2a8763892bcc1b6869f1b9913db34660e245df77/src/resolvers/git.cr#L181-L189
So the spec I mentioned can be added later when that TODO is implemented. Yay!
Rebased on master to solve conflicts
Changing the source from git to path in the shard.yml, in the precense of a shard.lock file didn't trigger an update of the lockfile. The
outdated_lockfile?
logic didn't consider all the information that will be used to generate that file (resolver key and source were missing).Now lock constraints are not added if the resolver from the shard.yml and from the shard.lock differ.
It will now handle better ambiguous sources for the same name. Before this PR one was used because the cache was accessed by name only. Now it depends on name, key and (normalized) source.
The resolver cache needed to be reset in some helper methods on integration specs to avoid misleading results. Well, now that the cache key depends not only in the name that change is not really needed, but I think is better to isolate that. The cache was designed for the solver and that is not used in the integration specs.