Upgrading to the latest MCMChains results in Turing downgrading from v0.13.0 to v0.7.1. Has anyone else had this issue? Is there a workaround? In the meantime, I’ve pinned Turing to prevent the downgrade.
Should I report this as an issue?
Thanks.
1 Like
I noticed this also. What I did, after a comment in the Slack channel, was to ] add Turing@0.13.0 but then it downgraded MCMCChains.
1 Like
Welcome to the Curse of Julia
Where important_Package_A depends on unimportant_Package_B
Then unimportant_Package_B goes up a version which forces
the important_Package_A to downgrade to a much lower version!!!
I don’t think that’s a good characterization of the issue here - while I don’t have deep knowledge of Turing’s internals, I think MCMCChains is quite a crucial dependency for a package that does Bayesian estimation using… Markov Chain Monte Carlo methods.
The PR fixing this issue is already pending here, and as @Torkar says above you can just explicitly install the version of the “important” (to you) package, which then means you’ll work with an older version of the “unimportant” (to you) package, which, almost by definition, seems to be okay!?
2 Likes
Don’t blame a system which tries to protect your software integrity. Communicate your dependency issues to the devs (issues) and I am sure they will do their best to check and test the compatibility. They usually have a working dev-environment and running the test suite should be a no-brainer. Alternatively, create a PR with the updated dependencies (it’s really just the Project.toml) and the CI should usually be executed and will tell you and other if it works. For this, you really only need a web browser since you can edit files on GitHub directly.
Welcome to the Curse of Julia
The “curse” is that you can be quite safe that the compatibility is given. There are many ways defining compatible versions (unlike to other dependency managers like used in PyPI), see here 6. Compatibility · Pkg.jl and the compatibility checking is doing its best to figure out which package versions to combine, all the way down to the last dependency.
This means, the developers have a really flexible way to communicate what they have tested (or what they assume to be working) and approved to be installed.
I think the bigger problem is that in many projects (I was also doing this but trying to improve) only fixed versions are listed, which of course leads to issues when packages get updated.
The other problem is that there are still many 0.x packages and I personally do not feel good adding something like "^0 to a dependency which means everything is supported from 0.0.1 up to and excluding 1.0.0 (see 6. Compatibility · Pkg.jl).
I however tend to write ^1 since according to SemVer, it should theoretically be non-breaking up to (and excluding) 2.0.0.
In my opinion, more packages should go to 1.0.0 since it would make the dependency management a little bit more flexible. On the other hand, no-one guarantees that any update will work, so in principle a list of actually tested versions is actually the most secure way.
…and finally, it’s always the question whether you want to use the latest and greatest, or something which is more likely to work (together). In scientific projects where reproducibility is crucial, frequent updates of dependencies are not so common (well, during the first prototyping phase it’s a different story).
4 Likes
For me, this term evokes images of dusty corridors in pyramids teeming with mummies, or castles with vampires and werewolfes. In any case, it is way to cool to waste on a single issue.
Thus I propose that we should set up a registry for the Curses of Julia. Users could refer to their current most irksome issue by UUID. Hooks in the Discourse forum would automatically link the relevant item in this registry, allowing sentences like “Julia is doomed unless Curse 999aee00-afdc-11ea-b3de-0242ac130004 is resolved.”
5 Likes
Which is what I did. Having Turing at 0.13.0 is more important to me than having the latest MCMCChains. So, I did as you mentioned and then pinned Turing to prevent it from downgrading again.
Sorry, I wasn’t trying to start a heated discussion. Yes, I find the dependency issue annoying, but, I’m only an end user and all I can do is trust the developers to do what they think is best.
So, for future reference, I should feel free to report issues like this to the devs? Probably a better idea than mentioning them here. 
You should absolutely report such issues! Dependencies evolve and it’s incredibly hard to keep track of everything as a package developer. Keep in mind that you are using this software for free, so the least you can do is to give feedback (and cite it 
)
1 Like
I’ve been somewhat hesitant to post issues because I’m unsure at times if what I want to report actually belongs there. I definitely want to help by providing feedback. I just don’t want to waste people’s time by posting issues that aren’t legitimate.
As for citing, definitely! I would love to see more mentions of Julia in peer-reviewed literature, especially in ecology. If I manage to finish my dissertation work, I’ll definitely make my contribution.