DrChainsaw (Jan 25 2024 at 10:05): DrChainsaw (Jan 25 2024 at 10:05):Is there any "trick" to make the Pkg resolver to prefer one package over another without forcing the user to explicitly install a version.
The background is this: I have a package A which depends on LightXML which in turn depends on XML2_jll. A while back I saw that XML2_jll made a non breaking release 2.12 which included more rigorous validation. The problem is that the xmls my package needs to read are no longer considered valid by 2.12.
As a fix I made a new release of package A which locks the version of XML2_jll to 2.11. However, now it seems that Pkg prefers to install the old version of package A (probably due to the version number delta of XML2_jll being higher) when installing package B (which depends on package A).
Is there some way to fix this (apart from adding a dependency to XML2_jll in package B as well I guess)?
Sukera (Jan 25 2024 at 10:07):you can make a PR to General to upperbound past versions of your package too
Sukera (Jan 25 2024 at 10:08):not a good solution though, a "proper" one would also mean investigating why the more rigorous validation means that your XMLs are no longer conforming
DrChainsaw (Jan 25 2024 at 10:12):you can make a PR to General to upperbound past versions of your package too
Hmm, yeah this could probably be doable. Package A is in a local registry but I suppose that just makes the process easier for me. What is the mechanism for this exactly? Make new branches from past releases and overwrite the git sha in Versions.toml, or is there a less heavy handed way?
not a good solution though, a "proper" one would also mean investigating why the more rigorous validation means that your XMLs are no longer conforming
Of course, but in this case it is not feasible unfortunately since I don't own or control the xml files.
Sukera (Jan 25 2024 at 10:14):no, just make a PR and change the Compat.toml for your package
Sukera (Jan 25 2024 at 10:15):the Compat.toml has sections of version ranges of your package, which then contain the accepted version ranges of dependencies for those versions of your package
DrChainsaw (Jan 25 2024 at 10:19):Yeah, that seems to be much easier. I suppose this implies that the Project.toml of dependencies is ignored when resolving package versions then?
Sukera (Jan 25 2024 at 10:21):good question, but it does seem like that
Sukera (Jan 25 2024 at 10:22):I just know that there were cases in the past were packages got retroactively upperbounded in the registry, without cutting a new release
Sukera (Jan 25 2024 at 10:22):might want to ask in slack in the pkg-registration channel though, my knowledge about the resolving algorithm is very superficial
DrChainsaw (Jan 25 2024 at 10:29):Thanks! Since it is a local registry I can probably afford to be a bit gung ho and see if it causes issues.
Notification Bot (Jan 25 2024 at 10:29):DrChainsaw has marked this topic as resolved.
Gunnar Farnebäck (Jan 25 2024 at 10:41):The biggest difficulty is usually to find the correct syntax to use in the updated Compat.toml.
Last updated: Dec 28 2024 at 04:38 UTC