Dependency problem with FIllArrays

General Usage
1

I am in the process of switching my packages to using Project.toml.
When trying to add to the project.toml of ControlSystemIdentification.jl, I get the following problem

(ControlSystemIdentification) pkg> add LinearAlgebra
 Resolving package versions...
ERROR: Unsatisfiable requirements detected for package FillArrays [1a297f60]:
 FillArrays [1a297f60] log:
 ├─possible versions are: [0.0.1, 0.1.0, 0.2.0-0.2.1, 0.3.0, 0.4.0, 0.5.0, 0.6.0] or uninstalled
 ├─restricted to versions 0.6.0 by an explicit requirement, leaving only versions 0.6.0
 └─restricted by compatibility requirements with TotalLeastSquares [028f657a] to versions: [0.0.1, 0.1.0, 0.2.0-0.2.1, 0.3.0, 0.4.0, 0.5.0] — no versions left
   └─TotalLeastSquares [028f657a] log:
     ├─possible versions are: 0.1.0-0.1.1 or uninstalled
     └─restricted to versions * by an explicit requirement, leaving only versions 0.1.0-0.1.1

This line in the General registry,
FillArrays = “0.0-0.5”
indicates that TotalLeastSquares, which is my package, is not compatible with the latest version of FillArrays, which is 0.6.0. I have not put that upper cap myself, and I believe it is compatible.

If I manually go in and edit the registry on my local machine to FillArrays = "0.0-0.6", it works okay. My question is, why was the cap on v0.5 put there for TotalLeastSquares? And how should I go about resolving my issue?

2

When the converter script from METADATA to General ran, it set upper bounds on all dependencies as the semver compatible version of the last tagged version (I am not sure exactly why). To resolve it, I would just release a new TotalLeastSquares declaring compatibility with FillArrays 0.6 (which is a breaking version compared to 0.5).

3

Thanks, I have initiated the registration of a new release for TotalLeastSquares. Do I have to explicitly declare in Project.toml for TLS that I support v0.6 of FillArrays, or is it enough to tag this new release now that v0.6 of FA is tagged?

Edit: I realize that I do ahve to explicitly declare this, since no change to the cap is visible in
https://github.com/JuliaRegistries/General/pull/85/files

4

You can add FillArrays = "0.6" if you want to support [0.6 - 0.7) of FillArrays, cf 6. Compatibility · Pkg.jl.

5

Okay I’m lost, I have tried to declare
FillArrays = "0.5, 0.6"
in Project.toml for TotalLeastSquares, but that causes travis to fail with an “invalid version range”
How do I declare that I support both 0.5 and 0.6 of FillArrays? The special rules for 0.x confuse me a bit :confused:

6

Thats Registrators fault, should be fixed soon, see https://github.com/JuliaComputing/Registrator.jl/pull/90. Your Project.toml file is correct.

1 Like
7

Great, thanks for clarifying, I sure was confused there for a while. Stefan fixed my General PR manually so all is good now!

8

Can this be undone, please? It’s causing a huge headache, essentially everything needs to be retagged now…

1 Like
9

You only need to re-tag something if you want to be compatible with a dependency that has released a breaking version.

10

Or if we want users to use other packages that require the new version, since only one package version can be used at one time. This is going to make many packages unusable at the same time for no reason.

1 Like
11

It sounds like you want to completely turn off the resolver and just use the latest version of everything? I mean, if a package releases a breaking version then the packages that depend on it are going to have to updated to be compatible with that one (since it is breaking). That’s the whole point by choosing to set a version that is considered breaking according to semver.

1 Like
12

But when it’s 0.x a package is experimental, and so practically every version is “breaking” and often it’s breaking in a very small way where very few dependencies have to be changed.

1 Like
13

And it should be up to the package developers whether they want to have these upper bounds. Forcing them on all our packages is wrong.

14

From the docs (6. Compatibility · Pkg.jl):

While the semver specification says that all versions with a major version of 0 are incompatible with each other, we have made that choice that a version given as 0.a.b is considered compatible with 0.a.c if a != 0 and c >= b .

But it is? You can have

[compat]
Package = ">0.1"

to support anything higher than 0.1 (but note that that is not true, you can not guarantee that you are compatible with versions that is not even released yet). Even worse, you can leave out the compat completely and be “compatible” with everything.

2 Likes
15

I know, I’m referring to the upper bounds added “against our will” to my packages (and the OPs packages) on 11 April during the transition. I’m arguing these should be undone.

16

Those were added for good reasons (there was a long thread about it) and have been in place for ages. You have also been able to remove them for just as long in various ways. Nothing has changed now. It’s unclear to me why this is suddenly a big problem.

2 Likes
17

I wouldn’t call 6 days “ages”: tracking the history they were added on 11 April. It’s a big deal because it’s unintentionally breaking downstream packages like the OPs, and also forcing me to immediately tag new versions of about 10 packages for anything to work (the package manager just gives up if no compatible version is found) …

1 Like
18

I understand the default is the “tilde specifier” for [compat] of Project.toml. But isn’t the translation of REQUIRE the problem? The Julia 0.6 documentation says

For example, the line:

Distributions 0.1

is satisfied by any version of Distributions greater than or equal to 0.1.0.

This translates to Distributions = ">= 0.1" in Project.toml, right? If so, why a new upper bound is introduced in the conversion of METADATA to General?:

3 Likes
19

It didn’t matter since they were adjusted on each new sync, so the bounds were effectively >= 0.1.

20

Thanks, that explains why it has been working nicely. But I suppose it’s started to matter now that there no more METADAT-to-General conversion? That is to say, shouldn’t the information in General originated from REQUIRE files keep respecting the specification in the Julia 0.6 documentation?

1 Like