Or, more conservatively, you could get a message/PR from a bot telling you that you could extend those upper bounds because they passed CI.
To be fair, it is built into the syntax of REQUIRE to a certain extent; since it provides a default upper bound Inf
.
Saying that the code you have right now will support all future releases of a dependency is playing it loose imo. I do that do but I think we have to change that in the future because backport in upper bounds is just wrong.
Using the semver convention for breaking releases seems correct. You would then only need to revise the bounds if you want to claim compatability with a new breaking release of a dependency.
Agreed. I think the format changes in Pkg3 so that saying you support e.g. julia 0.6
means that you support [julia 0.6, julia 0.7-]
but I am not too sure of the detaila.
Yep, it is supposed to be handled by matching major.minor
as the default. In the scenario we are discussing, I think it would have done the right thing.
My problem was with a somewhat orthogonal issue in Pkg2
: that it downgraded without asking, then figuring out why took some digging. I usually do Pkg.update()
every morning while I have coffee and I donāt watch the output; this ensures I get all the bugfixes and developments. I am fine with it not upgrading, but downgrading broke a project where I was trying to load JLD2
files saved with DataFrames
v0.11.4
. Anyhow, I know this is going to be fixed, so no big deal.
In Pkg3 you can run each command in āpreview modeā which will show you the changes but not apply any of them. Furthermore, the error messages from the resolver have recently been greatly improved: https://github.com/JuliaLang/Pkg3.jl/pull/86.
I have the same problem now and not sure how and when it happenedā¦ Iām stuck with DataFrames 0.10.1 and have no idea whatās preventing an upgrade. The grep
command did not show anything suspicious (upper bound) eitherā¦ What can I do?
julia> Pkg.installed("DataFrames")
v"0.10.1"
$ grep DataFrames */REQUIRE
CSV/REQUIRE:DataFrames
DataFramesMeta/REQUIRE:DataFrames
DataStreams/REQUIRE:DataFrames
ExcelReaders/REQUIRE:DataFrames
Taro/REQUIRE:DataFrames
These updates do nothing:
julia> Pkg.update("DataFrames")
INFO: Updating METADATA...
INFO: Computing changes...
INFO: Package DataFrames was set to version 0.10.1, but a higher version 0.11.6 exists.
To install the latest version, you could try updating these packages as well: DataFramesMeta, CSV, Taro and ExcelReaders.
INFO: No packages to install, update or remove
julia> Pkg.update("DataFramesMeta")
INFO: Updating METADATA...
INFO: Computing changes...
INFO: Package DataFramesMeta was set to version 0.2.0, but a higher version 0.3.0 exists.
To install the latest version, you could try doing a full update with `Pkg.update()`.
INFO: No packages to install, update or remove
julia> Pkg.update("CSV")
INFO: Updating METADATA...
INFO: Computing changes...
INFO: Package CSV was set to version 0.1.5, but a higher version 0.2.4 exists.
To install the latest version, you could try doing a full update with `Pkg.update()`.
INFO: No packages to install, update or remove
julia> Pkg.update("Taro")
INFO: Updating METADATA...
INFO: Computing changes...
INFO: Package Taro was set to version 0.5.0, but a higher version 0.6.0 exists.
To install the latest version, you could try doing a full update with `Pkg.update()`.
INFO: No packages to install, update or remove
julia> Pkg.update("ExcelReaders")
INFO: Updating METADATA...
INFO: Computing changes...
INFO: No packages to install, update or remove
julia> Pkg.update()
INFO: Updating METADATA...
INFO: Updating WPkg master...
INFO: Updating Kafka master...
INFO: Computing changes...
INFO: No packages to install, update or remove
-
$(PACKAGE)/REQUIRE
is not definitive;METADATA/$(PACKAGE)/versions/I.J.K/requires
is. -
ExcelReaders
has been stuck on an old version ofDataFrames
for a while. - You are (or will soon be) in luck! DavidAnthoff recently (today?) made a release of
ExcelReaders
which cleans up the dependencies. - Or maybe not. Spreadsheets are designed to hide mistakes.
I hit this yesterday when trying out JuliaPro. Unfortunately it was stuck on 0.10.1, so some existing code I have didnāt work.
It doesnāt matter for me because I just reverted to a standard Julia install, but it will be nice once the dependencies get resolved and JuliaPro uses 0.11.
Yes, ExcelReaders.jl and ExcelFiles.jl are just waiting for one METADATA tag and then should no longer hold anything back.
True, you touched a nerve here. Back when I faced this issue, my Julia Pro install gave me a lot of trouble with dependencies, which got messier after a RCall related update. I postponed my transition to the Julia data ecosystem till the next Julia Pro which will hopefully smoothen these dependencies out.
we are almost at julia version 1.0 now, which should resolve a lot of the ambiguity about whether 0.6.2, or 0.7 is the right target for package (dataframe) developers.
I would recommend that you consider just installing the plain vanilla binary, along with your favorite editor/IDE. As much as I respect the effort that went into JuliaPro, perhaps it is not ideal for a fast-moving package ecosystem.
I ran into similar issues with JuliaPro and decided to do radical surgery (not for the faint of heart!)
- Backed up the Julia projects I was working on.
- Backed up file [path to]\JuliaPro-0.6.2.2\pkgs-0.6.2.2\v0.6\REQUIRE
- Deleted all entries in the REQUIRE file and saved it.
- Launched JuliaPro command prompt and ran Pkg.resolve()
As a result all packages got uninstalled. - Pkg.add(āDataFrameā)
- Pkg.add(āIJuliaā)
- Pkg.add(āPlotsā)
- Pkg.add(āwhatever other packages I neededā)
Problems fixed.
My heart skipped a beat when I deleted REQUIRE, but this surgery worked.
@Tamas_Pappās suggestion was what I was doing so far but the previous incarnation of Julia Pro was put together really well and provided the comfort that an Ubuntu LTS provides for instance. In any case, this issue forced me to step out of Julia Pro and try out the vanilla binary + IJulia + installing-packages-I-need approach and I realize that it (i.e., handling dependencies, etc) is not really as scary as it seems when you begin. At the end of it all, it was more of me being used to R + Rstudio-ish all-in-one stable go-to solution rather than anything else.