# How Does Compat Requirement Changes for General Registry Affect Package Maintainers?

**URL:** <https://discourse.julialang.org/t/how-does-compat-requirement-changes-for-general-registry-affect-package-maintainers/104960>\
**Category:** General Usage\
**Tags:** compatibility, general-registry\
**Created:** [October 14, 2023, 7:47pm UTC](https://discourse.julialang.org/t/how-does-compat-requirement-changes-for-general-registry-affect-package-maintainers/104960 "2023-10-14T19:47:54Z")\
**Posts on this page:** 18\
**Page:** 1

<div class="post-metadata">

**Author:** ![TheCedarPrince](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/thecedarprince/32/17323_2.png) [@TheCedarPrince](https://discourse.julialang.org/u/TheCedarPrince)\
**Post date:** [October 14, 2023, 7:47pm UTC](https://discourse.julialang.org/t/how-does-compat-requirement-changes-for-general-registry-affect-package-maintainers/104960/1 "2023-10-14T19:47:54Z")

</div>

Hi folks!

This is a post about the recent announcement:

> [@PSA: Compat requirements in the General registry are changing](https://discourse.julialang.org/t/psa-compat-requirements-in-the-general-registry-are-changing/104958):
>
> TL;DR: Currently standard libraries have an implied version number based of the Julia version. This is changing and will require users to update their Project.toml. Update – November 9th 2023: While rolling this change out we encountered some [unfortunate interactions](https://discourse.julialang.org/t/why-random-jl-is-fixed-to-version-0-0-0/105957/2). Namely that using Pkg inside the test sandbox would lead to confusing errors like: Resolving package versions... ERROR: LoadError: Unsatisfiable requirements detected for package LinearAlgebra [37e2e46d]: LinearAlgebra [37e2e…

I was curious about a few things here:

1. How does this impact packages that support testing of older Julia versions which did not have this segmentation of standard libraries? At first glance, it almost seems like I have to create a separate Project.toml for these older Julia versions (pre 1.10) that I test my packages on and another toml for these Julia versions after 1.9.
2. What was the thought process behind this separation of standard libraries from the main Julia distribution?

The 1st question is more coming from me as a package developer and wondering what I should do to accommodate these changes going forward. The 2nd was more just curiosity and what the perceived benefits are about it.

Thanks!

~ tcp 🌳

---

<div class="post-metadata">

**Author:** ![TheCedarPrince](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/thecedarprince/32/17323_2.png) [@TheCedarPrince](https://discourse.julialang.org/u/TheCedarPrince)\
**Post date:** [October 14, 2023, 7:49pm UTC](https://discourse.julialang.org/t/how-does-compat-requirement-changes-for-general-registry-affect-package-maintainers/104960/2 "2023-10-14T19:49:43Z")

</div>

Also, just saw this post: [Question about new stdlib compact requirements](https://discourse.julialang.org/t/question-about-new-stdlib-compact-requirements/104961) which seems to be asking some similar questions! Maybe we could combine discussion here @longemen3000?

---

<div class="post-metadata">

**Author:** ![longemen3000](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/longemen3000/32/7298_2.png) [@longemen3000](https://discourse.julialang.org/u/longemen3000)\
**Post date:** [October 14, 2023, 7:50pm UTC](https://discourse.julialang.org/t/how-does-compat-requirement-changes-for-general-registry-affect-package-maintainers/104960/3 "2023-10-14T19:50:04Z")

</div>

Yes! I will close mine

---

<div class="post-metadata">

**Author:** ![abraemer](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/abraemer/32/51403_2.png) [@abraemer](https://discourse.julialang.org/u/abraemer)\
**Post date:** [October 14, 2023, 8:45pm UTC](https://discourse.julialang.org/t/how-does-compat-requirement-changes-for-general-registry-affect-package-maintainers/104960/4 "2023-10-14T20:45:24Z")

</div>

About 2): IIUC there are essentially no real benefits of having a library in the base sysimage. If the runtime itself uses some functionality from a library, then this library needs to be part of the base sysimage. Separating libraries from the sysimage also decouples the library from the release process of Julia itself, so you don’t need to wait for a new release to get basic bugfixes. Another nice bonus is improved startup time, since you don’t have to load libraries you don’t use.

---

<div class="post-metadata">

**Author:** ![vchuravy](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/vchuravy/32/8_2.png) [@vchuravy](https://discourse.julialang.org/u/vchuravy)\
**Post date:** [October 14, 2023, 8:54pm UTC](https://discourse.julialang.org/t/how-does-compat-requirement-changes-for-general-registry-affect-package-maintainers/104960/5 "2023-10-14T20:54:55Z")

</div>

> [@TheCedarPrince](#):
>
> How does this impact packages that support testing of older Julia versions which did not have this segmentation of standard libraries? At first glance, it almost seems like I have to create a separate Project.toml for these older Julia versions (pre 1.10) that I test my packages on and another toml for these Julia versions after 1.9.

There should be no effect on older versions of Julia. `Julia 1.6` implies `Statistics 1.6` and vice-versa.

> [@TheCedarPrince](#):
>
> What was the thought process behind this separation of standard libraries from the main Julia distribution?

Stdlibs will still be distributed along-side Julia, some were part of the system image primarily for latency reasons. E.g. to lower the startup time of Julia REPL and Pkg were both baked into the system image.

With package images the latency cost of not having them in the system image is acceptable, this means we are more moving to a “if you use it you have to pay for it”. E.g. if I run Julia as a webserver and I never need REPL and Pkg, why am I required to load them by default. Julia will startup faster (as long as you don’t load the REPL) and use less memory.

Lastly “standard libraries is where code goes to die”, the development process for standard libraries was clunky and unlike any other Julia packages and their release cycle bound to the Julia release cycle.

This has lead to the (social) development that rather than contributing and improving standard libraries, folks (including me) have rather preferred working on new packages that extend standard libraries. Why wait 3-6 months for your bug fix or feature to be available if you could release an package version in 15 minutes…

Making standard libraries upgradeable gives us the freedom to put out quicker releases for them, including bug-fixes and respond to CVEs more flexibly.

---

<div class="post-metadata">

**Author:** ![vchuravy](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/vchuravy/32/8_2.png) [@vchuravy](https://discourse.julialang.org/u/vchuravy)\
**Post date:** [October 14, 2023, 8:57pm UTC](https://discourse.julialang.org/t/how-does-compat-requirement-changes-for-general-registry-affect-package-maintainers/104960/6 "2023-10-14T20:57:09Z")

</div>

Over the next week or so we will be PRs like [Add compat for Distributed by vchuravy · Pull Request #93409 · JuliaRegistries/General · GitHub](https://github.com/JuliaRegistries/General/pull/93409) that add compat information on historical basis.

---

<div class="post-metadata">

**Author:** ![longemen3000](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/longemen3000/32/7298_2.png) [@longemen3000](https://discourse.julialang.org/u/longemen3000)\
**Post date:** [October 14, 2023, 9:28pm UTC](https://discourse.julialang.org/t/how-does-compat-requirement-changes-for-general-registry-affect-package-maintainers/104960/7 "2023-10-14T21:28:41Z")

</div>

> [@vchuravy](#):
>
> Making standard libraries upgradeable gives us the freedom to put out quicker releases for them, including bug-fixes and respond to CVEs more flexibly.

This sounds dumb, but does this mean that the versions of the standard libraries will, in time, diverge from the current julia version?

---

<div class="post-metadata">

**Author:** ![vchuravy](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/vchuravy/32/8_2.png) [@vchuravy](https://discourse.julialang.org/u/vchuravy)\
**Post date:** [October 14, 2023, 10:00pm UTC](https://discourse.julialang.org/t/how-does-compat-requirement-changes-for-general-registry-affect-package-maintainers/104960/8 "2023-10-14T22:00:47Z")

</div>

> [@longemen3000](#):
>
> This sounds dumb, but does this mean that the versions of the standard libraries will, in time, diverge from the current julia version?

Not a dumb question at all. Short answer yes.  
The goal is for stdlibs to “just” be normal Julia libraries,  
with the oy difference that a initial version is shipped with a distribution of Julia.

---

<div class="post-metadata">

**Author:** ![TheCedarPrince](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/thecedarprince/32/17323_2.png) [@TheCedarPrince](https://discourse.julialang.org/u/TheCedarPrince)\
**Post date:** [October 14, 2023, 10:22pm UTC](https://discourse.julialang.org/t/how-does-compat-requirement-changes-for-general-registry-affect-package-maintainers/104960/9 "2023-10-14T22:22:08Z")

</div>

Ah! Thanks for explaining @vchuravy – this allays all my concerns. In fact, I think this is pretty fantastic! So going forward, if I install a fresh Julia installation (\>1.9), would I not only want to do something like install the Julia version I want but also figure out what packages I want?

I’d imagine wanting the following packages in my environment:

1. Julia Base
2. Julia REPL
3. Julia Banner
4. Shell Mode
5. Pkg Mode

And install it somehow before first opening Julia? Like `julia -e 'Pkg.add(["REPL.jl", "Pkg.jl", ...)` and then run `julia` from the shell like normal?

---

<div class="post-metadata">

**Author:** ![vchuravy](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/vchuravy/32/8_2.png) [@vchuravy](https://discourse.julialang.org/u/vchuravy)\
**Post date:** [October 14, 2023, 10:26pm UTC](https://discourse.julialang.org/t/how-does-compat-requirement-changes-for-general-registry-affect-package-maintainers/104960/10 "2023-10-14T22:26:13Z")

</div>

Note that the stdlibs are still shipped with Julia so you shouldn’t need to add them to their environment it to get a REPL working, but yes you could update the version of Downloads.jl being used in your Project.

This change is meant to be non-breaking so as Julia works today it should work on 1.11. The one difference is that you may notice us compiling newly cached versions of standard libraries 😉

---

<div class="post-metadata">

**Author:** ![TheCedarPrince](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/thecedarprince/32/17323_2.png) [@TheCedarPrince](https://discourse.julialang.org/u/TheCedarPrince)\
**Post date:** [October 14, 2023, 10:56pm UTC](https://discourse.julialang.org/t/how-does-compat-requirement-changes-for-general-registry-affect-package-maintainers/104960/11 "2023-10-14T22:56:31Z")

</div>

Ah gotcha gotcha. Thanks for explaining!

I am however letting my mind run wild a little bit with fun ideas for Julia REPL “distros” that one could build. Exciting times!

---

<div class="post-metadata">

**Author:** ![Olivier\_Merchiers](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/olivier_merchiers/32/4073_2.png) [@Olivier\_Merchiers](https://discourse.julialang.org/u/Olivier_Merchiers)\
**Post date:** [October 15, 2023, 12:00am UTC](https://discourse.julialang.org/t/how-does-compat-requirement-changes-for-general-registry-affect-package-maintainers/104960/12 "2023-10-15T00:00:01Z")

</div>

Hi,  
Thanks for taking the time to explain all of this.  
There is still one point I don’t really understand.  
How can I stdlib be shipped with julia but not be in the sysimage?

---

<div class="post-metadata">

**Author:** ![vchuravy](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/vchuravy/32/8_2.png) [@vchuravy](https://discourse.julialang.org/u/vchuravy)\
**Post date:** [October 15, 2023, 1:27am UTC](https://discourse.julialang.org/t/how-does-compat-requirement-changes-for-general-registry-affect-package-maintainers/104960/13 "2023-10-15T01:27:36Z")

</div>

We actually have been doing so for a while.

Julia has two concepts that control the behavior of package loading, `LOAD_PATH` and `DEPOT_PATH`. Both function as a sort of stack, where we start our search with first entry and if we are unsuccessful we proceed to the next entry:

```julia-repl
julia> Base.DEPOT_PATH
3-element Vector{String}:
 "/home/vchuravy/.julia"
 "/home/vchuravy/.julia/juliaup/j" ⋯ 20 bytes ⋯ "x64.linux.gnu/local/share/julia"
 "/home/vchuravy/.julia/juliaup/julia-1.10.0-beta3+0.x64.linux.gnu/share/julia"

```

and

```julia
julia> Base.LOAD_PATH
3-element Vector{String}:
 "@"
 "@v#.#"
 "@stdlib"

```

The default depot path on your system contains: First the mutable user depot, then the `local/share/julia` and lastly the global `share/julia`. The `local/share/julia` is by default empty and the `share/julia` contains all the things that we distributed along-side Julia.

```julia
share/julia> ls
base/ base.cache cert.pem compiled/ julia-config.jl* stdlib/ test/

```

In `stdlib/v1.10/` is the source code for all of the stdlibs (corresponding to the LOAD\_PATH entry `@stdlib`) and in `compiled/v1.10` are the corresponding cache files.

Already early one not all stdlibs were baked into the system image, but rather we load them on demand.

Hope that helps!

---

<div class="post-metadata">

**Author:** ![Olivier\_Merchiers](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/olivier_merchiers/32/4073_2.png) [@Olivier\_Merchiers](https://discourse.julialang.org/u/Olivier_Merchiers)\
**Post date:** [October 15, 2023, 9:00am UTC](https://discourse.julialang.org/t/how-does-compat-requirement-changes-for-general-registry-affect-package-maintainers/104960/14 "2023-10-15T09:00:00Z")

</div>

Thank you so much!  
That was quite an AHA moment for me!  
Much clearer indeed

---

<div class="post-metadata">

**Author:** ![stevengj](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/stevengj/32/71_2.png) [@stevengj](https://discourse.julialang.org/u/stevengj)\
**Post date:** [October 18, 2023, 4:41pm UTC](https://discourse.julialang.org/t/how-does-compat-requirement-changes-for-general-registry-affect-package-maintainers/104960/15 "2023-10-18T16:41:55Z")

</div>

> [@vchuravy](#):
>
> There should be no effect on older versions of Julia. `Julia 1.6` implies `Statistics 1.6` and vice-versa.

I’m getting a [CI failure for the Richardson.jl](https://github.com/JuliaMath/Richardson.jl/actions/runs/6563449135/job/17827708633#step:21:66) package after adding a version requirement for LinearAlgebra:

```julia
   Testing Richardson
 Resolving package versions...
ERROR: LoadError: empty intersection between LinearAlgebra@0.0.0 and project compatibility 1.0.0-1

```

Apparently the package manager for Julia 1.0 thinks that LinearAlgebra is version 0.0.0.

Does this only work with Julia 1.6 or later?

---

<div class="post-metadata">

**Author:** ![vchuravy](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/vchuravy/32/8_2.png) [@vchuravy](https://discourse.julialang.org/u/vchuravy)\
**Post date:** [October 18, 2023, 7:45pm UTC](https://discourse.julialang.org/t/how-does-compat-requirement-changes-for-general-registry-affect-package-maintainers/104960/16 "2023-10-18T19:45:48Z")

</div>

> [@stevengj](#):
>
> Does this only work with Julia 1.6 or later?

That’s the oldest version I tested… It may be that this was fixed later.

---

<div class="post-metadata">

**Author:** ![Tamas\_Papp](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/tamas_papp/32/25949_2.png) [@Tamas\_Papp](https://discourse.julialang.org/u/Tamas_Papp)\
**Post date:** [October 30, 2023, 2:07pm UTC](https://discourse.julialang.org/t/how-does-compat-requirement-changes-for-general-registry-affect-package-maintainers/104960/17 "2023-10-30T14:07:11Z")

</div>

I am getting the same problem with FiniteDifferences.jl,

> <https://github.com/JuliaDiff/FiniteDifferences.jl/pull/229>

I do not think that Julia 1.0 supports compat entries for stdlibs.

---

<div class="post-metadata">

**Author:** ![ericphanson](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/ericphanson/32/215186_2.png) [@ericphanson](https://discourse.julialang.org/u/ericphanson)\
**Post date:** [October 30, 2023, 3:21pm UTC](https://discourse.julialang.org/t/how-does-compat-requirement-changes-for-general-registry-affect-package-maintainers/104960/18 "2023-10-30T15:21:38Z")

</div>

@dilumaluthge has suggested using `"<0.0.1, 1"` to support old Julia versions, like in [this PR](https://github.com/JuliaRegistries/RegistryCI.jl/pull/526). And that SHA in particular needs `"<0.0.1, 0.7, 1"`.

It seems there was a Pkg bug that has since been fixed which requires this setting, because during testing at different parts in thinks the stdlib versions as `v0.0.0` at times, so the package needs to be compatible with `v0.0.0` to be loadable.

From my experimenting it seems Julia 1.0 to 1.3 needs this to be able to run tests at all, while some later Julia versions need this (and all their dependencies to have this) only if the test environment is re-resolved by e.g. `Pkg.add` during the tests.

It’s not clear to me which versions are affected by which version of the bug since there is no issue filed. Although @kristoffer.carlsson said on Slack that the bug is fixed, so that is good at least.