shards

shards copied to clipboard

Hello. If I have a shard.yml like this:

  kemal-session:
    github: kemalcr/kemal-session
    branch: master

and I change it to this:

  kemal-session:
    github: rdp/kemal-session
    branch: master

and run shards install I'd expect it to install...what I just changed it to. But it seems to re-use the earlier installed repo's version. Somewhat surprising...

Cheers!

Prob need to run shards update, otherwise it'll use the current shard.lock which probably still points to the old repo.

Protip, you can then run shards prune to remove unused libs.

No, shards install should notice when a dependency has changed. There are specs for this behaviour, it just seems to fail.

https://github.com/crystal-lang/shards/blob/df51076f52b2657c8cb32dfdb5edfce1ac985a2e/spec/integration/install_spec.cr#L296-L310

Possibly because it's pinned to a non-release version (branch: master) which isn't explicitly tested and has been missing in other implementations as well (#456).

Okay, so this is actualy not as clearly a bug as I thought, but I think it's still worth changing the current behaviour.

This topic has been discussed in #419, especially the thread https://github.com/crystal-lang/shards/pull/419#discussion_r454504116

The intention of the current behaviour targets the scenario when changing the source is only about the location, for example when a repository is renamed / relocated, but still refers to the same source semantically. In that case it's nice to have the same behaviour as without the source change and keep the locked version installed.

But for a use case like in the OP, the change to a different source is intential and meaningful. The user expresses to want "something else". When I change the source to a fork with newer commits I want to use those new commits and expect shards install to install them. Instead it seemingly stays with the old source.

Obviously, we can't tell both use cases apart. There's no way to know whether changing a source is intended to keep the same semantics as the previous source or supposed to invalidate the lock.

I would prefer the latter semantics, though. For two reasons:

• While the current behaviour is more conservative, it's also more surprising in total: It's perfectly fine to disregard the lock restriction if the source has changed. Nobody will be surprised by that.
• It's probably more common to change sources because you need to use commits that are only available in a fork than shards being relocated.

I fiddled with some ideas to make the behaviour depend on the type of restriction and only apply to Ref restrictions. But I don't think that's working out because it would be too confusing to have different behaviours for this.

So I would really like to just change the behaviour to be less conservative and disregard lock restrictions if the source has changed. This would be the same as if you remove the dependency from shard.yml and then add it again (running shards install in between).

Yes that was my use case, thanks for your help :)

On 1/19/21, Johannes Müller [email protected] wrote:

Okay, so this is actualy not as clearly a bug as I thought, but I think it's still worth changing the current behaviour.

This topic has been discussed in #419, especially the thread https://github.com/crystal-lang/shards/pull/419#discussion_r454504116

The intention of the current behaviour targets the scenario when changing the source is only about the location, for example when a repository is renamed / relocated, but still refers to the same source semantically. In that case it's nice to have the same behaviour as without the source change and keep the locked version installed.

But for a use case like in the OP, the change to a different source is intential and meaningful. The user expresses to want "something else". When I change the source to a fork with newer commits I want to use those new commits and expect shards install to install them. Instead it seemingly stays with the old source.

Obviously, we can't tell both use cases apart. There's no way to know whether changing a source is intended to keep the same semantics as the previous source or supposed to invalidate the lock.

I would prefer the latter semantics, though. For two reasons:

• While the current behaviour is more conservative, it's also more surprising: It's perfectly fine to disregard the lock restriction if the source has changed. Nobody will be surprised by that.
• It's probably more common to change sources because you need to use commits that are only available in a fork than shards being relocated.

I fiddled with some ideas to make the behaviour depend on the type of restriction and only apply to Ref restrictions. But I don't think that's a good idea because it would be more complicated to understand what happens in what case.

So I would really like to just change the behaviour to be less conservative and disregard lock restrictions if the source has changed. This would be the same as if you remove the dependency from shard.yml and then add it again (running shards install in between).

-- You are receiving this because you authored the thread. Reply to this email directly or view it on GitHub: https://github.com/crystal-lang/shards/issues/465#issuecomment-763253847