FHIR Chat · Handling package-version conflicts

Stream: implementers

Topic: Handling package-version conflicts

Martin Höcker (Apr 19 2021 at 15:11):

I have the following FHIR packages: fhoo and bar. Note that they depend on different package-versions of some base-package:

{
 "name": "tld.name.fhoo",
 "version" : "1.0.0",
 "canonical" : "http://name.tld/fhoo",
 ...
 "dependencies": {
    "tld.name.base": "1.1.1",
 }
}

{
 "name": "tld.name.bar",
 "version" : "1.0.0",
 "canonical" : "http://name.tld/bar",
 ...
 "dependencies": {
    "tld.name.base": "1.2.2",
 }
}

How is this version conflict resolved when I use fhoo and bar in a "child"-package?

{
 "name": "tld.name.child",
 ...
 "dependencies": {
    "tld.name.fhoo": "1.0.0",
    "tld.name.bar": "1.0.0",
 }
}

The strategy used by npm is to allow for both versions of the base-package to be used simultaneously, but I'm not sure if that works well for me. For example, even if the package-version is different, the business-version of the individual resources might still be the same as before. In this case, the content of those resources should be the same, but this is not guaranteed (technical corrections that don't change the business-content might still be applied).

To be safe, I would probably err on the side of caution and use a maven-like version resolution strategy, where automatically the latest version is used (and a warning is emitted to the implementer). Would this be a suitable approach to the problem?

Grahame Grieve (Apr 19 2021 at 23:28):

I don't know how that's resolved. And I don't even know what the current tooling would do

Martin Höcker (Apr 21 2021 at 18:10):

I experimented a bit with SUSHI. It looks like SUSHI circumvents this problem by not automatically resolving transitive package dependencies. If you want to use profiles or other resources that are defined in a transitive dependency, you have to explicitly list this dependency in the sushi-config.yaml. If you don't, then there is a simple "not found"-error for the resource you are trying to use.

But I'm not sure how deliberate this choice in conflict-resolution-strategy was. Could you weigh in, @Chris Moesel ?

I have not yet tried it with firely terminal.

Chris Moesel (Apr 21 2021 at 18:59):

So... you're right. SUSHI requires you to explicitly list transitive dependencies if you will be using anything from them. I don't think this was intentional; it was probably more of an oversight. The thing that NPM has that we don't is wildcard versioning -- which allows more flexibility to find a single version of a transitive dependency that satisfies all requirements (if requirements don't require an explicit exact version). But... we don't have that so... I see two potential approaches: If there are conflicting versions of a transitive dependency,

Use the most recent version (of the specified transitive dependencies), OR
Require the user to explicitly specify what version to use by including it as a direct dependency (like SUSHI unintentionally requires now)

Of course there are still all sorts of fun things that can happen since parts of dependency StructureDefinitions can be embedded in other profile definitions (due to traversing into the structure). So, just because we might have a way to choose a version to use does not mean we are out of the woods! I guess the only way to solve that problem is to allow each dependency to have access to its own sub-dependencies (without choosing a "common" version) -- but that gets pretty complex and I'm not really sure what it means for interoperability either...

Lloyd McKenzie (Apr 21 2021 at 22:11):

I think requiring explicitly listing dependencies that should be inherited through an existing dependency is going to result in maintenance pain (at some point the version references are going to get out of sync).

Last updated: Apr 12 2022 at 19:14 UTC

Main menu