Force dependency version

[duraki]

Today while upgrading my codebase to 0.27.0; I've stumble upon dependency issue; I couldn't lock a library to specific version. The only similar issue is at #12. Related to kemalcr/kemal-session#70.

Example of kemalcr/kemal-csrf:

...
dependencies:
  kemal-session:
    github: kemalcr/kemal-session
    version: 0.10.0 # => locks kemal-session to 0.10.0

Example of crecto/crecto-admin#shard.yml:

...
  kemal-csrf:
    github: kemalcr/kemal-csrf

  kemal-session:
    github: kemalcr/kemal-session
    
    # => should lock kemal-session to master (0.11.0), but can't since kemalcr/kemal-csrf
    version: 0.11.0
    branch: master 
...

As seen above, the first snippet is dependency of the library, in this case kemal-session. The second snippet is from "any" project and shard.yml listed.

If for some reason we wanted to use latest version of kemal-session, we wouldn't be able:

$ shards update
Fetching https://github.com/schovi/baked_file_system.git
Fetching https://github.com/crecto/crecto.git
Fetching https://github.com/crystal-lang/crystal-db.git
Fetching https://github.com/kemalcr/kemal.git
Fetching https://github.com/luislavena/radix.git
Fetching https://github.com/jeromegn/kilt.git
Fetching https://github.com/crystal-loot/exception_page.git
Fetching https://github.com/kemalcr/kemal-csrf.git
Fetching https://github.com/kemalcr/kemal-session.git
Error resolving kemal-session (0.10.0, 0.11.0) // ERROR

Allow developer to run, or force shard lock on base project, rather than parent lib/dep.

[straight-shoota]

This looks to be expected behaviour. If one dependency depends on version 0.10.0 and another on 0.11.0 of the same share, there is no resolution to these restrictions. They can't both be met. Using either of them violates one of the restrictions, so it should obviously be an error.

[duraki]

How about a flag to force dependency of the base project rather than parent/library dependency? It makes more sense imo to follow developers resolution, instead of using dependency version. How would one deal with this situation? (in my case, I had to make two separate forks to fix this, which I could fix easily if I were allowed to set custom version lock).

[bcardiff]

Duplicate or it could be solved if #105 is done.

[straight-shoota]

@duraki Using a shard with a dependency it isn't supposed to work with, is never a good idea. You can obviously override that by putting whatever version in lib, but I don't think shards should have support for anything like this.

The solution is to make the other shard's dependencies match up. Not to loosen restrictions on dependency resolution.

[ysbaddaden]

This is expected. Both constraints are strict exact matches: =0.10.0 and =0.11.0 which is impossible to resolve. Both libraries are incompatible and they must solve this. For example by upgrading and releasing a new version to use 0.11.0, or use loose constraints instead of exact matches.

[duraki]

Nop, loose constraints (~) instead of exact matches does not work since each of those can't resolve which one is "primary" (one provided by third-party library, or one provided by application developer).

[RX14]

@duraki if the shard's shard.yml doesn't allow you to use the version, then that's expected behaviour. You need to take that up with the shard author or make a fork.

[duraki]

@RX14 Strange expected behavior. Any specific reason? It makes absolutely no sense to relay on author or library dependency especially issue-wise. Lets say I find a vulnerability in third-party library used by any shard or app, if a fix was pushed to that lib, my application would stay vulnerable until author of third party library updated the code.

Check composer/composer#6126 on how this was solved for unofficial PHP package manager using additional flag.

[ysbaddaden]

They're good example of why library authors MUSN'T use exact matches, that are prone to fail very quickly, and prevent updating to security patches. Libraries should use loose constraints, such as ~> 0.10 and ~> 0.11 that would fix the compatibility issues, and allow security upgrades, and so on.

Please bug the library authors to fix their dependencies.