ModuleDependencies and Version

[canzanos]

I'm finding the overral reliability of ModuleDependencies, Versions to be unreliable.

I have tried using * as a way of indicating that when I install Module A which is dependent on Module B with Version *. My expectation is that when I install Module A it will

1. check to see if Module B is installed. If it is not installed ZPM will install Module B. This part works,
2. Check if Module B is install, if it is but the remote registry has a higher version then I feel like it should install the latest version of Module B. This part is not working
3. If I defined in Module A a dependency on Version 2, even though I have Module B Version 2 installed but it is on Version 1 I run into issues like

Could not find satisfactory version of rclib-rcipm in any repositories. Required by: rclib-wellbase: 2.1.0; rclib-ccdprofile, rclib-arcgis, rclib-logviewer, rclib-hs: *; rclib-fhir: 1.3.2

[isc-tleavitt]

@canzanos in your example error message what's Module A, what's Module B, and what are you trying to install?

This looks like rclib-fhir (already installed) needs a specific version of rclib-rcipm, and rclib-wellbase (already installed) needs a different specific version of rclib-rcipm. Dependencies can be declared using semver ranges (see https://github.com/npm/node-semver#ranges for description) so maybe what you really need is for rclib-fhir to require >=1.3.2 and rclib-wellbase to require >=2.1.0?

[isc-tleavitt]

It would be good to improve the error message here to explicitly state that there are conflicting version requirements, rather than indicating that we can't find a version that satisfies an impossible-to-satisfy set of constraints.

[isc-dchui]

@isc-tleavitt
Thinking about this issue a bit, answering the question of "is it mathematically possible to solve the constraints" vs "is there an accessible version that solves the constraints" is a somewhat different and more difficult problem. It would likely require solving boolean satisfiability which adds a whole lot of complexity and computation that I'm not sure is worth the cost.

Even if we manage to implement that, it would change the error message to either
a) There exists a hypothetical version that would satisfy the requirements, but no registry contains such a version
or b) The version requirements are mathematically impossible to solve.

But the most actionable step in both cases is likely to modify the version requirements if possible, which begs the question of what was the point of proving it was mathematically impossible.

All this is to say it might just be better to add a line to the error message like, "Note: the version requirements may be impossible to satisfy. Please check and adjust dependencies and required versions if possible."

[isc-tleavitt]

Agreed on adding that line - BUT: I do think that for the simple case of:

• Package A requires exact version X
• Package B requires exact version Y
• (maybe other stuff too, but because A and B both have a locked version it doesn't matter)

We could be a bit more helpful in O(n) without getting into super crazy algorithms.

[SCanzano-ready]

I'm trying to follow this but I'm still confused.
We have many modules, most all have specific dependencies on other modules with the same version. For example we have a collection of modules that are all version

rclib-rcreportsbasic 1.9.0 ...

and the dependencies are on others where we have


rclib-rcipm
1.9.0

if we install all of the modules so that we are all on version 1.9.0

and we want to upgrade to 1.10.0 we currently have to uninstall everything and install 1.10.0
If we simply try to install 1.10.0 we get the error message identified in the original post.

I dont think we are doing anything specifically complex.

[isc-dchui]

@SCanzano-ready I believe the requirement to keep all modules and their dependencies on the same version makes it a tricky problem for you. The upcoming upgrade framework should help make the process smoother, but as I understand it, because you have many top level modules depending on a specific version of a base module, you'll need to uninstall all before you can reinstall the new version.

An alternative would be to allow for more version flexibility. For example, let's say you have ModuleA, ModuleB, and ModuleC all dependent on BaseModule. Let's also say they are currently on version 2.0.0 and you are trying to update them all to 2.1.0. You can define ModuleA/B/C 2.0.0 to be dependent on BaseModule ^2.0.0 and ModuleA/B/C 2.1.0 to be dependent on BaseModule ^2.1.0. This way ModuleA, ModuleB, and ModuleC can each be updated in turn, with the first update also updating BaseModule to 2.1.0.

This does depend on 2.1.0 being backwards compatible with 2.0.0 and being ok with the module versions being out of sync with each other while the updates are happening.

[isc-dchui]

What would really help is a -force flag for the update command, i.e. saying update -force <parent-module> [<new-version>] should update not only the parent module but all dependencies too.