Restricting the version of an indirect dependency

General Usage
,
1

The HTTP package is not in my project file, but I would like to restrict its version and upgrade everything else. I have not been able to find a direct way of doing this, so I upgraded everything, then added it to my project with a version restriction and then deleted it from the project again, i.e.

using Pkg
pkg"up -m"
pkg"add HTTP@1.10"
pkg"rm HTTP"

Is this the best way to do this?

2

Why not make it a direct dependency?

3

You can add it as a [weakdep]. Then restrict its version using [compat]. That’s the same mechanism used by package extensions. Reading through Pkg · The Julia Language this is not really well documented either (actually I’m not even sure this can work)

4

Thanks @langestefan , your suggestion works and I think that it is the right solution.

@Benny the reason that I did not want to add HTTP as a direct dependency is that I do not use it directly in the project. Theoretically, if the package that depends on it removes that dependency, then there would be no need for it in Project.toml

5

If you care about its version, though, then that’d seem like you care about it enough to list it as a direct dependency… even if you’re not directly using it. Or perhaps the thing you really care about is the compat clause of a direct dependency?

6

Wouldn’t that be a stale dependency? Then Aqua.jl would trip over it.

I don’t know what the usecase for OP is but I’ve had to do this in the past as a temporary fix, when a breaking change in a dependency of one of my dependencies broke my package

7

XLSX.jl is an extension package of my CasualPlots.jl, and XML.jl, which is an upstream dependency of XLSX.jl, had a regression on one specific version. I excluded that version by adding it as a [weakdep], exactly as suggested above, and it actually worked, at least on Github CI.

Adding XML.jl as a direct dependency would be not justified, because XLSX.jl is, well, an extension of my package, and thus XML.jl doesn’t need to be necessarily loaded in all use cases.

8

XML.jl has downsteam tests to prevent these kinds of issues.

In this case the problem slipped through because I had set the downsteam tests to run on julia 1.12, but Julia 1.10 has a compiler bug that was triggered by the use of that specific XML.jl version with XLSX.jl. The downstream tests are now being run on both 1.12 and 1.10. There are other compiler bugs in 1.10 that might be triggered by different combinations of check-bounds and coverage, but there are only so many things we can test (and hopefully we can drop support for 1.10 at some point).

Maybe there are downsteam tests that should be added to HTTP.jl so you can reliably use the latest version?

9

I have a project that has just been using the same manifest for ages and when I upgraded all packages, then I got some intermittent stacktraces from HTTP. I didn’t need any new features from HTTP so I just wanted to use the easy solution for now where I just kept HTTP on the version that I was using before. The package that uses HTTP when the stacktraces occur is one that I have made myself and I will probably change it to use Downloads instead, so version restricting HTTP is also basically a temporary solution.