JuliaCIBot on Modia fails for Julia 1.0, but Travis is successful

General Usage
1

A pull request was made at METADATA to register the new Modia 0.2.1 release which is the first version of Modia supporting Julia 0.7 and 1.0. Travis CL on this release was successful for Julia 0.6, 0.7, 1.0.

The JuilaCIBot was successful for Julia 0.6 and 0.7, but failed for Julia 1.0. The reason seems to be some issue with the package manager. However, from the JuliaCIBot log, I cannot figure out the reason, or what I need to do to fix this. The essential messages in the log are:

[...]
Fast-forward
 Modia/versions/0.2.1/requires | 7 +++++++
 Modia/versions/0.2.1/sha1     | 1 +
 2 files changed, 8 insertions(+)
 create mode 100644 Modia/versions/0.2.1/requires
 create mode 100644 Modia/versions/0.2.1/sha1
[...]
ERROR: Unsatisfiable requirements detected for package Modia [cb905087]:
Modia [cb905087] log:
 ├─possible versions are: 0.2.0-0.2.1 or uninstalled
 ├─restricted to versions * by an explicit requirement, leaving only versions 0.2.0-0.2.1
 └─restricted by julia compatibility requirements to versions: uninstalled — no versions left

It seems that JuliaCIBot installs two Modia versions at the same time and “somehow” wants to use them and then treats this at some point in time as an error.

The reason could be that the Project.toml file and the METADATA registry had different UUIDs for Modia 0.2.0 (I do not know why this mix-up occured). For Modia 0.2.1, the UUID in the Project.toml file was changed to the UUID in the METADATA registry.

Help is appreciated

2

Cf:

and the solution for me was using the UUID from the registry.

(I just updated the package generator skeleton.jl to work around this, and use METADATA-compatible UUIDs when generating new packages.)

3

I see that Modia.jl has a Manifest.toml checked in. Not 100% sure, but I believe that the current practice for working with METADATA.jl is to not do this. You need a REQUIRE file and you can have a Project.toml file, but not a Manifest.toml, I think. At least I don’t do it for my packages. I’m not sure where/whether this is documented; I was at least expecting this information in the README.md for METADATA.jl, but it appears it hasn’t been updated for 0.7/1.0.

1 Like
4

Thanks, this explains the reason for the different UUIDs.

5

Hm. Modia has both, a REQUIRE file and Project.toml/Manifest.toml files. The reason for this is that Modia supports Julia 0.6 and 0.7/1.0. I was not aware that Project.toml/Manifest.toml should not yet be used.

Note, for two related packages this worked: ModiaMath is already registered and has a REQUIRE and Project/Manifest.toml files. Besides the UUID issue, there was no problem with the registration. Modia3D has also all three files and registration is currently pending (JuliaCIBot is successful for 0.6, 0.7, 1.0).

6

The issue was that the “Dates” package was included in the REQUIRE file. After removing it from the REQUIRE file, JuliaCIBot was successful for Julia 0.6, 0.7, 1.0.
The details of this problem are described here.

It would have helped if the error message

ERROR: Unsatisfiable requirements detected for package Modia [cb905087]:
Modia [cb905087] log:
 ├─possible versions are: 0.2.0-0.2.1 or uninstalled
 ├─restricted to versions * by an explicit requirement, leaving only versions 0.2.0-0.2.1
 └─restricted by julia compatibility requirements to versions: uninstalled — no versions left

would have included the name of the package that caused the failure.

7

@StefanKarpinski or @kristoffer.carlsson, what is the current situation regarding checking in Manifest.toml files for packages (see earlier comment)?

I don’t think it’s possible to do that in general, i.e. in general there is not a unique subset of packages that ‘deserves the blame’ for causing unsatisfiability.

8

Checking in a Manifest is fine, it is not really used for anything except when someone sets the package as the “active project”. Also, tests will be run with the versions given in the Manifest.

1 Like
9

It might be possible to give better error messages in some cases but this requires a pretty significant overhaul of the version resolver. I’ve started on that but it’s not anywhere near done yet.