I thought that the new package manager has the big advantage that if package A requires package B in the version defined in the Project.toml file, then whenever A is used, it uses package B with this version, under all circumstances (so using package A is reliable).
However, by accident I recognized today that this seems to be not the case (I am using Julia 1.0.1):
Package Modia uses internally package ModiaMath, version 0.2.4. When having an environment without ModiaMath, then Modia in fact uses this version. However, when having an environment in which Modia is present and ModiaMath, version 0.2.5-dev, then Modia uses ModiaMath version 0.2.5-dev and not version 0.2.4.
I wonder whether this undesireable behaviour is related to the still present REQUIRE file? Should the REQUIRE file be just removed, when a Project.toml file is present? However, then the information is missing which Julia version is supported by the package, because this information seems to be only present in the REQUIRE file but not in the Project.toml file.
deving a package makes all of your packages utilize this development version. This is to make it easy to see how a package modifies others. If you want to prevent this behavior, then you should develop in an environment. But just to be clear, a user will get 0.2.4.
Only one manifest is used, in particular, the toplevel one. When you add Modia the Manifest.toml file in Modia is ignored.
Only one version of a package can be loaded (specified from by the toplevel Manfest.toml), so Modia will never use “its own” version, it will use the same as you get when you using ModiaMath from the toplevel code.
Yes, looks like a bug. What happens here is that you are not completely removing ModiaMath, since it is required by Modia. So 0.2.5-dev is still in the Manifest.toml file. For some reason
which should error, since, from a clean env this should happen:
(sandbox) pkg> add ModiaMath@0.2.3
Resolving package versions...
ERROR: Unsatisfiable requirements detected for package ModiaMath [67ccffd1]:
ModiaMath [67ccffd1] log:
├─possible versions are: 0.2.0-0.2.4 or uninstalled
├─restricted to versions 0.2.3 by an explicit requirement, leaving only versions 0.2.3
└─restricted by julia compatibility requirements to versions: 0.2.4 or uninstalled — no versions left
Thanks for this clarification, although it is not fully clear: Assume, package Modia3D also uses ModiaMath, but another version, say 0.2.3. When both Modia and Modia3D are used in the current environment (but not ModiaMath), it seems the same thing will happen as in Julia 0.6: ModiaMath 0.2.4 (the version required from Modia) will be used from Modia3D (and from Modia). However, if Modia3D was not developed to work with ModiaMath 0.2.4, it will suddenly fail (just by adding an unrelated package). So, if this is really the case, then Julia 1.0 seems to have again a fragile package management (as in Julia 0.6).
I still hope that this is just a temporary issue that is resolved once the REQUIRE file can be removed.
Thank you for the clarification. Obviously, I have misunderstood the new package manager.
The consequence seems to be that a “normal” user (who is using Julia and packages from the Julia community for production work) needs to rely on pre-configured distributions (such as JuliaPro), where someone takes the effort to combine compatible packages in a distribution. I have hoped that this is no longer needed.
Sure, I agree. However, if by accident a non-backwards compatible change is made to a package, say ModiaMath 0.2.5, and then a user package A is used (which uses ModiaMath 0.2.4), then A is correctly working if it is alone in an environment (using ModiaMath 0.2.4). If another package B is added to the environment that uses ModiaMath 0.2.5, then ModiaMath 0.2.5 is used for A and A will fail. So adding an unrelated package B to the environment will result in a failure of an already available package A.
When starting with Julia (0,5), some time ago, this was actually happening: Adding a package A to Julia was fine. Then adding an (unrelated) package B, suddenly A did no longer work. Sometimes, adding again A, suddenly allowed to use both A and B, but in other cases one could either use A or B, but not both. The remedy for me was to use JuliaPro and to no longer try to add packages myself.
I hoped that this situation would be solved by the new package manager, but it seems this (very hard) problem is still pending.