I’m using ControlSystems a lot but I have several issues with it.
In particular, when I’m doing ] up (I’m generally doing it for other reasons not related to ControlSystems), ControlSystems and its dependencies update as well and it is always breaking my Julia environment. It has already happened 2 different times this last month.
Please tell me what I’m doing wrong and how should I fix my workflow. It takes me hours upon hours to fix these issues, which I think can be easily avoided through compatibility and versioning.
Unfortunately, you didn’t elaborate what exactly breaks in your environment, so I can’t help you with that. But you always can pin the version of ControlSystems by running ] pin ControlSystems@x.y.z to prevent updating this package (where x.y.z is the version that works for you)
WARNING: could not import OrdinaryDiffEq.DiffEqBase into ControlSystems
ERROR: LoadError: UndefVarError: `DiffEqBase` not defined in `ControlSystems`
Stacktrace:
[1] top-level scope
@ ~/.julia/packages/ControlSystems/KuzoR/src/simulators.jl:49
[2] include(mod::Module, _path::String)
@ Base ./Base.jl:557
[3] include(x::String)
@ ControlSystems ~/.julia/packages/ControlSystems/KuzoR/src/ControlSystems.jl:1
[4] top-level scope
@ ~/.julia/packages/ControlSystems/KuzoR/src/ControlSystems.jl:22
[5] include
@ ./Base.jl:557 [inlined]
[6] include_package_for_output(pkg::Base.PkgId, input::String, depot_path::Vector{String}, dl_load_path::Vector{String}, load_path::Vector{String}, concrete_deps::Vector{Pair{Base.PkgId, UInt128}}, source::String)
@ Base ./loading.jl:2881
As far as I understand, it is a problem related to ControlSystems dependencies, thus won’t help fixing ControlSystems version, I should fix the version of all its dependencies.
Deleting the manifest and doing resolve was not helping either. The only way I found out to unlock my environemnt was to go into the Manifest and change back all the package versions.
Wasn’t working for me, and it broke on the ] up, so unless the fix was done on the next version (i.e. 1.17.x instead of 1.16.y), I don’t know why it didn’t update.
If you have a local Project.toml file, add a compat section (also explained in the link above) and enter in this [compat] section the version numbers of the packages you need in the combination that works well, like this:
[compat]
ControlSystemsBase = "~1.15.1"
You can use ~ or = in front of the version number. ~ allows minor updates.
If you have a Project.toml file with a correct compat section you can always use Pkg.update() to update the indirect dependencies and nothing should break.
Furthermore, if you have a well tested state of your project, make a backup copy of your Manifest.toml file, like this:
cp Manifest.toml Manifest-v1.11.toml.default
and add this copy to git.
Furthermore, often ControlSystemsBase.jl is good enough (and much faster to install) then ControlSystems.jl .
If you did these steps and still have problems, please post the output of
using Pkg
Pkg.status()
You asked for alternatives to ControlSystems.jl . Well, we cannot answer this question if we do not know which problem you are trying to solve. If you tell us more, we might be able to suggest alternatives.
Check your Project.toml and Manifest.toml files into source control. Also record what Julia version you are using (newer Julia versions store that info in the manifest for you).
Just before you do pkg> up, commit your current project and manifest files. At this point, you can also push to a remote (e.g. a private GitHub repo) if you want.
Do the pkg> up, and then see if anything breaks.
If something has broken, just revert to the previous commit, because you know that commit has a working manifest.
I’d probably recommend using Git as your source control system. But this approach should in theory work with any source control system.
To save some clicks, the reason is that ControlSystems formerly did import OrdinaryDiffEq: DiffEqBase, but an update to OrdinaryDiffEq switched from importing DiffEqBase (directly at least) to the lightweightSciMLBase. The other modules and types a package imports and extends are internal details subject to change unless documented to be stable user-level features, and as far as I can tell, the heavy re-exporting makes it so that users of OrdinaryDiffEq aren’t intended to directly reference DiffEqBase. ControlSystems is free to separately use DiffEqBase as an internal dependency, which is the fix, though it could potentially switch to SciMLBase in the future.
Bit of an aside, importing a likely internal dependency of a direct dependency is currently the typical practice in extensions that can’t safely import dependencies other than its trigger packages. Besides being unfeasible for wholly independent internal types (I might want to crunch StaticArrays in an extension for packages that don’t use it), a direct dependency changing or omitting an internal import can break that extension forever.
It’s good to use pkg> add --preserve=all or some of the other options there. Or for
up --preserve=<all/direct/none>
I wish this was the default in Julia, at least an option to never downgrade… which is likely your problem.
Save your Manifest.toml file, then you at least know how your exact working setup was like, and you can easily revert.
I add packages to my (global) environment like crazy (or have to test out intriguing packages), and I’m sure it doesn’t help. I’m adopting a better workflow since it’s a bad habit.
Sometimes downgrades are a problem, not sure about this one, any downgrade seems like a step backwards to me, so I want to eliminate the possibility (but then maybe you can’t install until you figure out what’s blocking and fixing that):