Here, it basically means that one of the test dependencies (Plots) is not compatible with the versions resolved for the package (which includes StatsBase 0.30).
Oki thanks. Unfortunately, I still do not understand how the resolver came to say restricted to versions 0.30.0 by an explicit requirement, leaving only versions 0.30.0, could it be made to say where the explicit requirement came from?
The problem is not that the package itself does not support 0.29, it does. The problem is that a test-dependency (Plots) does not support the version that the package would use if that test dependency was not there.
Okay, I somewhat understand after reading the discussion in the issue, thanks. So if I would like my tests to pass, the only option I have other than waiting for dependencies to update, is to say that I only support StatsBase v0.29 for now, since Plots only support v0.29 at the moment?
As it is right now, if a test dependency is not compatible with the versions of packages that gets resolved without the test dependency, the package will fail with a resolution error when tested.
The workaround is to check in a Manifest with versions that are compatible with the test dependencies. We should maybe think more about https://github.com/JuliaLang/Pkg.jl/issues/110 and loosen how hard the version of project dependencies are being kept.
My understanding about the practicalities of checking in the Manifest.toml into the repo is the following, is this correct?
for users of the package, who installed it via pkg> add or pkg> dev, the Manifest.toml in the package directory is ignored entirely, so this is innocuous,
it is used for pkg> test ThatPackage, so then it is useful (the only harm is that it may fetch some earlier versions of various packages, but again that is fine),
for CI, it will use that exact test environment, which has some benefits, but also negates some of the advantages of CI (testing with package versions which I don’t happen to have installed on my computer). This can be worked around by doing a Pkg.update() in the CI script; if it works it is fine, if it breaks then the manifest works as a backup.
Yes, the manifest is only “active” if the project for that package is the current Project for example by starting with --project in that directory.
It is used when running test on the current active project (which is the case in CI). It is not used for test ThatPackage unless ThatPackage is the current active project.
For CI, if a manifest is checked in, it will be used (since the active project will be that of the package).
Thanks. With the manifest checked in, is it a good idea to do a
Pkg.update()
then in the CI (eg Travis) script? My concern is that I may forget to keep updating the manifest regularly and could be testing a configuration that is no longer relevant as packages moved on.
I’m not sure if you are replying to me but anyway, I just pointed out the technical reason why test Plots fail. If you didn’t find it useful, perhaps someone else will.
My argument is that introducing upper bounds in General when there is no such declaration in the original REQUIRE files (and not updating them) is wrong.
The sentence you quoted is misleading without the preceding part:
First of all, I’m not claiming that loose compatibility declaration is the best software practice. I’m talking about the specification of the REQUIRE/Project.toml format and the correctness of the implementation.
If the compatibility for a dependency is not given, the project is assumed to be compatible with all versions of that dependency.
Does this mean “maximally “semver”-compatible version of the version existed at the time of the registration?” What about the >= specifier? If that’s the case, I think it is better to clarify as such in the documentation.
If that’s not the case, i.e., there is a facility to express “compatible with all versions”, I don’t understand why the information in REQUIRE files is not faithfully translated.
Having said that, I do 100%-agree with
for post-1.0 semver-compatible software. I’m ambivalent about it for pre-1.0.