# Registry for docs CI not updated?

**URL:** <https://discourse.julialang.org/t/registry-for-docs-ci-not-updated/94807>\
**Category:** General Usage\
**Tags:** documenter\
**Created:** [February 17, 2023, 7:54pm UTC](https://discourse.julialang.org/t/registry-for-docs-ci-not-updated/94807 "2023-02-17T19:54:31Z")\
**Posts on this page:** 2\
**Page:** 1

<div class="post-metadata">

**Author:** ![lmiq](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/lmiq/32/18314_2.png) [@lmiq](https://discourse.julialang.org/u/lmiq)\
**Post date:** [February 17, 2023, 7:54pm UTC](https://discourse.julialang.org/t/registry-for-docs-ci-not-updated/94807/1 "2023-02-17T19:54:31Z")

</div>

Is there any reason for the Julia registry to remain outdated in the Docs CI only?

I’m having trouble with this run: [update compat entry · m3g/ComplexMixtures.jl@606dc97 · GitHub](https://github.com/m3g/ComplexMixtures.jl/actions/runs/4205021871/jobs/7300769786)

Which fails with a compatibility problem:

```julia
 ERROR: Unsatisfiable requirements detected for package CellListMap [69e1c6dd]:
 CellListMap [69e1c6dd] log:
 ├─possible versions are: 0.2.3-0.8.11 or uninstalled
 └─restricted to versions 0.8.12-0.8 by ComplexMixtures [6f35c628] — no versions left
   └─ComplexMixtures [6f35c628] log:
     ├─possible versions are: 0.6.2 or uninstalled
     └─ComplexMixtures [6f35c628] is fixed to version 0.6.2

```

The `ComplexMixtures.jl` package version there is correct, and it is compatible with `CellListMap v0.8.12`, which is already available from the general registry (thus all other CI runs work well).

In this Documenter run, it seems that it first installs version `0.6.0` (not `0.6.2`) of the package:

```julia
   Installing known registries into `~/.julia`
    Updating registry at `~/.julia/registries/General.toml`
   Resolving package versions...
.... # many packages
   Installed CellListMap ───────── v0.8.11
   Installed ComplexMixtures ───── v0.6.0

```

and, it seems, this later breaks the installation of 0.6.2, which depends on the newer 0.8.12 version of the other (`CellListMap`) package. I think I messed up in some compat entry in the `0.6.0` version of the problematic package, but that was solved in `0.6.2` and, effectively, all other CI runs work fine.

The issue is only on the docs deployment. I was expecting the run to install the newest versions of the 0.6.X series of the package with its dependencies, and that works fine. I cannot reproduce the issue locally, either.

Any idea?

---

<div class="post-metadata">

**Author:** ![mortenpi](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/mortenpi/32/158_2.png) [@mortenpi](https://discourse.julialang.org/u/mortenpi)\
**Post date:** [February 18, 2023, 1:32am UTC](https://discourse.julialang.org/t/registry-for-docs-ci-not-updated/94807/2 "2023-02-18T01:32:11Z")

</div>

I am also getting `v0.6.0` when I install locally, so I think it’s due to the eager/conservative package server issue, and the conservative (default) package server has fallen behind the General registry a little bit right now.

> <https://github.com/JuliaLang/Pkg.jl/pull/3330>
>
> I really think the current default flavour is wrong. I would argue that 99.99% o…f users do not care if they download a package / artifact from the Pkg server or GitHub. They much rather have the latest version and there are quite frequent questions about why a user gets an old version installed, even though it was x hours since it got registered. As it is right now, if the package server processes a package slowly, all registered versions after that are blocked for everyone which imo is quite unacceptable. The recent reported blockage was ~18 hours from what I recently read which imo is not really acceptable.
> 
> In special cases, where you are e.g. behind a fire wall so you cannot talk to GitHub you want to use the conservative version since otherwise you might fail the download. But this is the special case so imo it makes more sense for these people to have to set some option.
> 
> cc @StefanKarpinski, @DilumAluthge .

I think the solution here would be to make CI use the eager registry. Otherwise, you can re-run that CI job in a day or so, and it will probably work.