# Restricting the version of an indirect dependency

**URL:** <https://discourse.julialang.org/t/restricting-the-version-of-an-indirect-dependency/138971>\
**Category:** General Usage\
**Tags:** package-manager, manifest\
**Created:** [August 21, 2026, 11:09am UTC](https://discourse.julialang.org/t/restricting-the-version-of-an-indirect-dependency/138971 "2026-08-21T11:09:13Z")\
**Posts on this page:** 10\
**Page:** 1

<div class="post-metadata">

**Author:** ![GHTaarn](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/ghtaarn/32/216007_2.png) [@GHTaarn](https://discourse.julialang.org/u/GHTaarn)\
**Post date:** [August 21, 2026, 11:09am UTC](https://discourse.julialang.org/t/restricting-the-version-of-an-indirect-dependency/138971/1 "2026-08-21T11:09:14Z")

</div>

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.

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

```

Is this the best way to do this?

---

<div class="post-metadata">

**Author:** ![Benny](https://avatars.discourse-cdn.com/v4/letter/b/49beb7/32.png) [@Benny](https://discourse.julialang.org/u/Benny)\
**Post date:** [August 21, 2026, 12:13pm UTC](https://discourse.julialang.org/t/restricting-the-version-of-an-indirect-dependency/138971/2 "2026-08-21T12:13:43Z")

</div>

Why not make it a direct dependency?

---

<div class="post-metadata">

**Author:** ![langestefan](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/langestefan/32/207923_2.png) [@langestefan](https://discourse.julialang.org/u/langestefan)\
**Post date:** [August 21, 2026, 12:31pm UTC](https://discourse.julialang.org/t/restricting-the-version-of-an-indirect-dependency/138971/3 "2026-08-21T12:31:51Z")

</div>

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](https://docs.julialang.org/en/v1/stdlib/Pkg/) this is not really well documented either (actually I’m not even sure this can work)

---

<div class="post-metadata">

**Author:** ![GHTaarn](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/ghtaarn/32/216007_2.png) [@GHTaarn](https://discourse.julialang.org/u/GHTaarn)\
**Post date:** [August 21, 2026, 1:33pm UTC](https://discourse.julialang.org/t/restricting-the-version-of-an-indirect-dependency/138971/4 "2026-08-21T13:33:37Z")

</div>

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

---

<div class="post-metadata">

**Author:** ![mbauman](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/mbauman/32/31082_2.png) [@mbauman](https://discourse.julialang.org/u/mbauman)\
**Post date:** [August 21, 2026, 1:48pm UTC](https://discourse.julialang.org/t/restricting-the-version-of-an-indirect-dependency/138971/5 "2026-08-21T13:48:03Z")

</div>

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?

---

<div class="post-metadata">

**Author:** ![langestefan](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/langestefan/32/207923_2.png) [@langestefan](https://discourse.julialang.org/u/langestefan)\
**Post date:** [August 21, 2026, 2:08pm UTC](https://discourse.julialang.org/t/restricting-the-version-of-an-indirect-dependency/138971/6 "2026-08-21T14:08:17Z")

</div>

> [@mbauman](#):
>
> then that’d seem like you care about it enough to list it as a direct dependency…

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

---

<div class="post-metadata">

**Author:** ![Eben60](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/eben60/32/13475_2.png) [@Eben60](https://discourse.julialang.org/u/Eben60)\
**Post date:** [August 21, 2026, 3:37pm UTC](https://discourse.julialang.org/t/restricting-the-version-of-an-indirect-dependency/138971/7 "2026-08-21T15:37:06Z")

</div>

> [@mbauman](#):
>
> If you care about its version, though, then that’d seem like you care about it enough to list it as a direct dependency

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.

---

<div class="post-metadata">

**Author:** ![nhz2](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/nhz2/32/44428_2.png) [@nhz2](https://discourse.julialang.org/u/nhz2)\
**Post date:** [August 21, 2026, 5:19pm UTC](https://discourse.julialang.org/t/restricting-the-version-of-an-indirect-dependency/138971/8 "2026-08-21T17:19:07Z")

</div>

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

> <https://github.com/JuliaData/XML.jl/blob/main/.github/workflows/Downstream.yml>

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?

---

<div class="post-metadata">

**Author:** ![GHTaarn](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/ghtaarn/32/216007_2.png) [@GHTaarn](https://discourse.julialang.org/u/GHTaarn)\
**Post date:** [August 21, 2026, 8:55pm UTC](https://discourse.julialang.org/t/restricting-the-version-of-an-indirect-dependency/138971/9 "2026-08-21T20:55:17Z")

</div>

> [@langestefan](#):
>
> 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

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.

---

<div class="post-metadata">

**Author:** ![Benny](https://avatars.discourse-cdn.com/v4/letter/b/49beb7/32.png) [@Benny](https://discourse.julialang.org/u/Benny)\
**Post date:** [August 21, 2026, 9:30pm UTC](https://discourse.julialang.org/t/restricting-the-version-of-an-indirect-dependency/138971/10 "2026-08-21T21:30:31Z")

</div>

> [@GHTaarn](#):
>
> 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

Specifying the package (by UUID) in `[weakdeps]` and restricting its version in `[compat]` still becomes Project.toml overspecification in that theoretical scenario, and it’s just as possible that HTTP shows up as an indirect dependency again or elsewhere. If you really need to avoid some versions of certain packages via Project.toml without freezing everything with Manifest.toml, overspecification is a risk you have to take.

The difference from direct `[deps]` is that `[weakdeps]` would be ignored when `instantiate`-ing the environment, saving some time and space in the theoretical scenario. Note that for [pre-1.9 backwards compatibility](https://pkgdocs.julialang.org/dev/creating-packages/#Backwards-compatibility), something listed in both `[deps]` and `[weakdeps]` would be treated as `[deps]` pre-1.9 and `[weakdeps]` 1.9+.