Closed PerMildner closed 11 months ago
This seems to happen when the given .msc
file has the same id
and version
as another - changing either fixes the problem
@cyderize Yes, as mentioned in the issue, the problem is precisely that the wrong information is used when there are multiple definitions of the same solver ID.
If I pass a solver config file using minizinc --solver ....msc I would expect this to be given preference when looking up tools and libraries.
Currently the ID seems to be taken from the passed configuration file but if there is also a globally installed configuration for the same ID, the tools and library of the latter are used instead of those specified in the configuration file.
This makes it hard to use alternative versions of a solver if a solver with the same ID is already globally installed.
In my case it is a problem when developing a solver, but presumably the same problem happens if you want to try out a new version of some of the default (or manually, globally), installed solvers.
In the following transcript there is a global configuration
sicstus.msc
for the idorg.sicstus.sicstus
(mentioned in~/.minizinc/Preferences.json
), and it works as expected, e.g. if usingminizinc --solver org.sicstus.sicstus ...
.However, if I instead pass a path to an alternative
sicstus.msc
using--solver
, what seems to happen is that the solver ID is taken from this alternativesicstus.msc
but then the default search is used to find the associated tools, instead of using the tool paths specified in the alternative `sicstus.msc'.The following uses a relative path to the configuration file, but the result is the same if an absolute path is used.