3 ms·

You’ve never found yourself in a dependency resolution situation where there are no solutions to requirements. You need multiple versions of the same package in

by baq 2y ago

You’ve never found yourself in a dependency resolution situation where there are no solutions to requirements. You need multiple versions of the same package in such cases. The alternative is just cheating: ignore requirements, install packages and hope for the best. Alas hope is not a process.

dikei 2y ago
The usual way is to put conflicting versions in optional-dependencies, and then build one target for each conflicting set of deps. That'd work fine if the code path of one target doesn't touch the others, which is often the case. You'd obviously need to have tests for both targets, possibly using a flexible test runner like `nox` to setup separate test env for each target.
theelous3 2y ago
I've never found myself in this situation where it can't be solved by being throughtful and taking the time to improve my code.
- leetrout 2y ago
  These issues crop up in dependencies more than your code. Then you have to vendor one of the deps and edit it (and hopefully ship that back upstream and hope the maintainer will merge it).
zokier 2y ago
No, the alternative is to just fix the code so that the conflict is removed. This is why open source is so powerful, you are empowered to fix stuff instead of piling up tower of workarounds.
- HelloNurse 2y ago
  You can fix your code, but indirect dependencies (you use A and B, both depend on C, but different versions of C) cannot be handled well. In C, C++, maybe Java, you would at least be able to link A and B with their own private copies of C to avoid conflicts reliably with standard mechanisms rather than unreliably with clever magical tools.
  - Too 2y ago
    You missed the point. If A, B and C are all open source you can actually fix them too. Just send a PR. Most projects are open to ensuring compatibility moves forward.
    - HelloNurse 2y ago
      Just send a PR? What are you talking about? A project that requires an old version of a dependency either has technically valid reasons, and is unlikely to be upgraded just because one more user asks nicely, or is maintained at a slow pace and/or with a low effort level, so that even if you do the work your patch is likely to be ignored (at least temporarily).
immibis 2y ago
You're viewing this from the perspective of a dependency resolution engine. From the perspective of a software engineer, the solution is to find better-behaved dependencies.

by baq 2y ago

dikei 2y ago

The usual way is to put conflicting versions in optional-dependencies, and then build one target for each conflicting set of deps. That'd work fine if the code path of one target doesn't touch the others, which is often the case. You'd obviously need to have tests for both targets, possibly using a flexible test runner like `nox` to setup separate test env for each target.

theelous3 2y ago

I've never found myself in this situation where it can't be solved by being throughtful and taking the time to improve my code.

leetrout 2y ago
These issues crop up in dependencies more than your code. Then you have to vendor one of the deps and edit it (and hopefully ship that back upstream and hope the maintainer will merge it).

zokier 2y ago

No, the alternative is to just fix the code so that the conflict is removed. This is why open source is so powerful, you are empowered to fix stuff instead of piling up tower of workarounds.

HelloNurse 2y ago
You can fix your code, but indirect dependencies (you use A and B, both depend on C, but different versions of C) cannot be handled well. In C, C++, maybe Java, you would at least be able to link A and B with their own private copies of C to avoid conflicts reliably with standard mechanisms rather than unreliably with clever magical tools.
- Too 2y ago
  You missed the point. If A, B and C are all open source you can actually fix them too. Just send a PR. Most projects are open to ensuring compatibility moves forward.
  - HelloNurse 2y ago
    Just send a PR? What are you talking about? A project that requires an old version of a dependency either has technically valid reasons, and is unlikely to be upgraded just because one more user asks nicely, or is maintained at a slow pace and/or with a low effort level, so that even if you do the work your patch is likely to be ignored (at least temporarily).

immibis 2y ago

You're viewing this from the perspective of a dependency resolution engine. From the perspective of a software engineer, the solution is to find better-behaved dependencies.