Compat entries for weakdeps on Julia <1.9

General Usage
,
1

Hello, I’m running into some trouble trying to get compatible versions of packages on old versions of Julia.

This situation could, in principle, arise with any package that uses extensions. However, to use a specific example, I’m observing this with LogDensityProblemsAD.jl and ADTypes.jl. The latter is a weakdep of the former, and:

On Julia 1.10 the compat entries are respected:

pkg> add LogDensityProblemsAD
pkg> add ADTypes@0.2
... ↓ LogDensityProblemsAD v1.9.1 ⇒ v1.9.0
pkg> st
⌃ [47edcb42] ADTypes v0.2.7
⌃ [996a588d] LogDensityProblemsAD v1.9.0

On Julia 1.7, though, they aren’t. I understand that this is because package extensions were only introduced in 1.9.

pkg> add LogDensityProblemsAD
pkg> add ADTypes@0.2
pkg> st
  [47edcb42] ADTypes v0.2.7
  [996a588d] LogDensityProblemsAD v1.9.1

Couple of questions:

  1. Is there a way to force Julia < 1.9 to respect the compat entries in the Project.toml? ADTypes is already listed under [extras] but Pkg doesn’t seem to use its compat entry.

  2. If not, what’s the best way to prevent this breaking on old versions of Julia? For more context, this issue is causing Turing.jl tests on Julia 1.7 to break. As a new user, I’m only allowed to put two links in my post, but it’s #2305 on the Turing issue tracker.

I know that the pre-1.9 way of doing extensions was Requires.jl, but I don’t see any way to enforce a version bound with that (correct me if I’m wrong).

2

This is something that package authors should make possible by following the explanation here:

https://pkgdocs.julialang.org/dev/creating-packages/#Transition-from-normal-dependency-to-extension

3

I see, thank you! This makes sense if the weakdep was originally a dep on the older versions.

In this case though the old version of LogDensityProblemsAD did not have ADTypes as a dep, it was just brought in via Requires.jl. I guess this was to avoid having to list multiple different AD frameworks in the dependencies.