I recently installed Julia 1.12.6 on Ubuntu 22.04.5. I then I tried to install FundamentalsNumericalComputation and had some issues. The issues were related to the packages BoundaryValueDiffEqFIRK (v1.13.0), BoundaryValueDiffEqMIRK (v1.13.0), BoundaryValueDiffEq (v5.21.0), DifferentialEquations (v7.17) and obviously FundamentalsNumericalComputation. None of these packages pre-compiled. There seems to be package conflicts.
I’m a bit stuck. I’ve tried creating an environment for an older Julia version and installing FundamentalsNumericalComputation there because I know it worked in older versions. The only problem with this is, for example, if I install Julia 1.10.9, I don’t know which version of FundamentalsNumericalComputation is compatible.
My main issue is installing FundamentalsNumericalComputation (v0.4.5) in Julia 1.12.6 and how to resolve the source of the conflicts. I honestly don’t know what to do. Can anyone suggest a fix?
I can confirm that after installing the LTS (1.10) via juliaup add lst, then setting juliaup default lts, then starting Julia, then switching to an empty dedicated environment by activate ., and then adding only the given package by add FundamentalsNumericalComputation, I also get an error: some complaints about failed compilation of
While addressing this particular issues is something with which perhaps @tobydriscoll could help, I take this as an opportunity to ask a more general but tightly related question:
Given a package that has not been updated for a few months, during which time a new version or even several versions may have been released, how do we reproduce the exact environment in which the package reportedly worked fine? The file Project.toml only contains compat entries for the packages, but for Julia itself, it only contains julia = "1.0", which seems not enough.
Here we could perhaps read the package release date (late 2024) and then look up the release date of the Julia version (perhaps LTS) released just before that… Is there any more systematic approach?
Tried to install it, got the same outcome as described, and the immediate cause appears to be BoundaryValueDiffEqCore.__initial_guess_on_mesh lacking a keyword tune_parameters when called by BoundaryValueDiffEqFIRK. It was patched here:
Basically the [compat] bounds of FIRK and MIRK weren’t initially updated when that method call was updated everywhere, so it was still possible to accidentally coexist with the old Core without the keyword.
Updating the environment failed, so the rest of FundamentalsNumericalComputation.jl is preventing that patch. That’s not what you want anyway to reproduce the software in a textbook. Unfortunately, the repo did not provide validated [compat] upper bounds or an exact manifest for reproducing the textbook’s environment; it’s structured like a package dependency for flexible updates and patches, which evidently discontinued and gathered version bugs. You could try to add the direct dependencies by exact major and minor versions (allowing most recent patch) listed in the project before adding the parent package. The Julia version at the time of the latest release was 1.10.6, though in principle you can get away with adding 1.10 for the latest patch.
If you do find a working environment and verify it works throughout the textbook, you could offer a stricter project and/or a manifest in an issue or pull request to the repo. It may not go anywhere, but at least people could try it for themselves.
In my packages, I always commit Manifest-v1.11.toml.default and Manifest-v1.12.toml.default as the last set of packages that the package was tested with. Unfortunately, most people are not doing that. And then, after a few years it is difficult to make old Julia projects work again. Often upper bounds in Project.toml are needed that are not known before things break.
UPDATE:
I created a fork that kind of works (on Julia 1.10; I did not test with other Julia versions).
Manifolds.jl’s last DiffEq v7 release is not compatible with the latest BoundaryValueDiffEq.jl, but doesn’t bound it. I think the best fix here is to put that upper bound into General. I’ll do this for them.
I still do not understand what we might have done wrong?
Also that is not related to the package here, I think since that does not use Manifolds, does it?
I still do not understand. (a) that broke because the SciML universe updated something (b) the fixes you linked above only fix stuff in SciML, not in our ecosystem. Yes that PR was necessary do adapt to your breaking changes…? I am just not sure what we could have done “correctly” here when the fix in the GR is unrelated to us?
Overall I by now feel, that I do not contribute well to the community and propose that I reduce my efforts then, when me trying to contribute causes so much work for others.
(for this thread I still think all this is a detour, sorry for that).
Not sure all of the details are relevant to the thread… but willing to share.
Yes, looks like it tracked down to something different. I knew that there was something going on in Manifolds.jl because of BoundaryValueDiffEq installation error · Issue #1136 · SciML/DifferentialEquations.jl · GitHub which pointed to ManifoldsBoundaryValueDiffEqExt as failing. It seems like it enters via Optmization.jl → OptimizationBase.jl → SymbolicAnalysis.jl → Manifolds.jl. Manifolds.jl’s ManifoldsBoundaryValueDiffEqExt then introduces some upper bound on BoundaryValueDiffEqCore (I think?) which then seems to be tripping on a bug where Sebasitan’s __initial_guess_on_mesh is missing a no keyword argument backport.
So surfacing that:
Now that I know Manifolds.jl has a ManifoldsBoundaryValueDiffEqExt, that should get updated so all on public API and not bounding, just did that.
General needs some bounds fixes to handle the breakage, just did that.
OptimizationBase.jl shouldn’t depend on SymbolicAnalysis.jl, that’s a really niche use case with a huge dependency tree and so this whole connection was pretty unnecessary. I will fix this myself.
This part I do not understand, where do we “upper bound” something? I mean sure we have compat entries that have an upper bound (that is actually mandatory I hope!) e.g. that RecursiveArrayTools was limited to "3" (otherwise GR would complain, right?), so I am also very confused why you say we upper bounded something.
I would not call this any win, if something randomly breaks (potentially my fault?) and I have zero understanding why and zero learning effect here. To me that is the total opposite of a win.
I don’t think RAT v4 was related. I’m not sure where the upper bound was coming from but I can track it down if you’re curious. I’m not sure how that’d be related to the robustness though since that was already diagnosed and if someone put an incorrect upper bound somewhere then that’s a one-time event.
So sorry for the confusion. I’ve been trying to clear up this process over the past few weeks, but there are still loose ends as I try to figure out what will be best for starter and power users alike.
To use the functions from the book, install FNCFunctions. Those are the functions presented within the text. It’s a fairly compact installation, though it has one heavy SciML dependency.
If you want to install all the dependencies for all the demos as well, you can get the Project file from julia-classroom and instantiate that. I can walk you through it by email if you don’t know how to do that. There are also instructions at that repo for setting up a VM version, but it turns out that the GitHub Codespace allocation isn’t up to the job.
(Source: Author of files and co-author of the book.)
DiffEq v8 drops more than half of its dependencies. I can help you get that update in. But separately wanted to make sure the other versions all worked out as well.
@kellertuer, I feel your pain. As a textbook author, I assume extra responsibility for trying to manage students’ first Julia experience, and I never lose the feeling that I keep getting it wrong, or at least less than ideal. Versioning has been a part of that.
I not am disparaging Pkg or the documentation in the slightest—dependencies are hard! Not for nothing does ‘dependency hell’ have its own Wikipedia page. At least we don’t have 2^12 competing package managers like some other ‘easy’ languages I could name.