Packages with different versions of a dependance

I have a piece of code using package A, and other piece using package B. Now I want to use them in the same project, but turns out packages A and B depend on a different version of a common dependence C - so Pkg cannot add them both. I’m not an author of neither A nor B (nor C for that matter), so cannot just update Project.toml in one of them to bump a version.

I hoped there is a way to force Pkg into installing a package ignoring its dependencies, or override this check in another way, but could not find anything related in the docs. Basically any other package manager I interacted with has an override flag for something like this, so that the user can quickly make it work and properly deal with the issue later. Of course, assuming that the needed parts of both A and B will actually work with a single version of C - seems like a reasonable assumption in many cases.

In my particular case A = LocalFilters.jl, B = NamedPlus.jl, and C = Compat.jl, if that’s important.

Any suggestions on how to install both packages together?

It looks like LocalFilters.jl saw its last substantial update before Julia reached v1.0. Most (if not all) of its functionality is also provided by Images.jl, which is actively developed and well-supported. Have you tried the Images.jl equivalents?

1 Like

Not tried yet. And my usecase here consists mostly of 1d arrays, so likely not the scope of Images.jl.

Also I had a similar Pkg issue before with another pair of packages, ended up splitting code that uses them into two different environment. This time I mostly wanted to find a more general way to solve it - a way that doesn’t involve migrating to a completely different package (if Images.jl even has functions I use), or having to split the project into two environment and pass serialized data between them.

Images.jl is written for arrays of arbitrary dimension, although I understand the desire to stick to what’s already working.

Pkg.jl doesn’t allow for the imposition of mutually-incompatible package requirements to an environment, so there’s no quick and dirty solution. The problem stems from LocalFilters.jl, which still uses a legacy REQUIRE file to specify dependencies. You may need to clone LocalFilters.jl, generate a Project.toml file as described in the first note here, and submit it as a pull request to the main repo (or just use the cloned version).

1 Like

Oh, didn’t know that. I guess the name doesn’t exactly help discoverability in this regard. Just looked at the docs for ImageFiltering - looks like it is not as general as LocalFilters yet. One thing I noticed is ImageFiltering requires some kind of border padding - it doesn’t just pass smaller arrays to the mapping function at the edges.
However, will look at those packages for my future code, thanks fot this suggestion!

That’s unfortunate - I held a hope that there is some escape hatch… Do you know if there are any plans to add an override flag?
The current situation - strict mandatory constrains that one cannot disable for a specific package - relies on authors to maintain their packages basically indefinitely. Otherwise an old package (that still works fine!) cannot be installed side-by-side with modern ones.

I’d forgotten the name earlier, but you may also want to look at RollingFunctions.jl, which covers a similar domain, but is explicitly meant for vectors.

The discoverability issue for Images.jl is well-known, but the main developers come from image processing, and we haven’t arrived at a more satisfactory name as of yet.

Regarding package compatibility, the current system (Pkg3) solves that problem by allowing specification of unlimited forward compatibility. During the transition between REQUIRES and Project.toml, a bridge was created to allow both systems to exist in parallel, but it’s developed some holes (as you found). Specifically, LocalFilters requires Compat v0.63+, which should overlap with NamedPlus’s requirement of Compat v3.1+, but the bridge (for this package) only goes up to v2.2, which is the version of Compat that existed when LocalFilters.jl was last updated.

It’s likely that packages will soon be required to have a Project.toml to stay listed in the main package repo, but until then, similar issues will keep cropping up.

Ok, I see - the issue should be, in a sense, temporary: only for packages created before Project.toml was used.

But I have another version incompatibility:

(tmp) pkg> add NamedPlus FINUFFT
  Resolving package versions...
ERROR: Unsatisfiable requirements detected for package BinDeps [9e28174c]:
 BinDeps [9e28174c] log:
 ├─possible versions are: [0.7.0, 0.8.9-0.8.10, 1.0.0-1.0.1] or uninstalled
 ├─restricted by compatibility requirements with FINUFFT [d8beea63] to versions: 0.8.10
 │ └─FINUFFT [d8beea63] log:
 │   ├─possible versions are: [0.1.0, 0.2.0, 0.3.0, 0.4.0-0.4.2] or uninstalled
 │   └─restricted to versions * by an explicit requirement, leaving only versions [0.1.0, 0.2.0, 0.3.0, 0.4.0-0.4.2]
 └─restricted by compatibility requirements with Compat [34da2185] to versions: 1.0.0-1.0.1 or uninstalled — no versions left
   └─Compat [34da2185] log:
     ├─possible versions are: [1.0.0-1.0.1, 1.1.0, 1.2.0, 1.3.0, 1.4.0, 1.5.0-1.5.1, 2.0.0, 2.1.0, 2.2.0, 3.0.0, 3.1.0, 3.2.0, 3.3.0-3.3.1, 3.4.0, 3.5.0, 3.6.0, 3.7.0, 3.8.0, 3.9.0-3.9.1, 3.10.0, 3.11.0] or uninstalled
     └─restricted by compatibility requirements with NamedPlus [c949b730] to versions: [3.1.0, 3.2.0, 3.3.0-3.3.1, 3.4.0, 3.5.0, 3.6.0, 3.7.0, 3.8.0, 3.9.0-3.9.1, 3.10.0, 3.11.0]
       └─NamedPlus [c949b730] log:
         ├─possible versions are: 0.0.1-0.0.4 or uninstalled
         └─restricted to versions * by an explicit requirement, leaving only versions 0.0.1-0.0.4

All relevant packages have Project.toml files, and version constrains seem compatible by eye. In FINUFFT.jl the constrain is BinDeps = "≥ 0.8.10", but Pkg doesn’t want to install a version newer than 0.8.10 for some reason.
Any idea of what goes wrong here? Lack of override means I cannot just force install the packages, but need to figure out what is wrong…

That seems buggy to me. @kristoffer.carlsson any idea why this is unsatisfiable when FINUFFT.jl requires BinDeps = "≥ 0.8.10" and NamedPlus has no dependence on BinDeps?