More registry status

[GunnarFarneback]

Extend the registry status command to show more information that can be useful for troubleshooting.

Example:

Registry Status 
 [xxxxxxxx] REDACTED (git@xxx)
    git registry, last updated 2025-07-03 14:11:13
 [23338594] General (https://github.com/JuliaRegistries/General.git)
    packed registry with hash d46462924dc723db4433cdc5cbc163529d12eba0, last updated 2025-07-03 14:11:13
    served by https://pkg.julialang.org (eager flavor) - update available

Feel free to bikeshed the layout and suggest more information that is useful and can easily be added.

The first commit updates the update log when a registry is first added. Without this the "last updated" information can be wildly wrong if a registry is removed at some point and much later added again.

I haven't looked into how this can be tested yet. It has some rudimentary testing now at least.

[Copilot]

Pull Request Overview

This PR enhances the registry status command by tracking when registries are added or updated and printing richer diagnostics.

• Persist registry update timestamps during registry download/install
• Improve status output with registry format, last-updated times, and package-server info
• Introduce get_registry_type helper for classifying registry layouts

Comments suppressed due to low confidence (2)

src/Registry/Registry.jl:628

• [nitpick] Public helper functions like get_registry_type should include a short docstring explaining the classification rules and return values to aid future maintainers.

function get_registry_type(reg)

src/Registry/Registry.jl:585

• The new status-printing logic and update-log handling lack automated tests. Consider adding unit tests for download_registries to verify correct timestamp storage and for status to validate the enhanced output formatting.

        registry_update_log = get_registry_update_log()

[KristofferC]

One way to test would be to run a registry status call, collect the ouput and see that it looks reasonable?

[IanButterworth]

Seems like the test might be flaky?
https://github.com/JuliaLang/Pkg.jl/actions/runs/16141733698/job/45550570860?pr=3266#step:5:214

registries: Test Failed at /home/runner/work/Pkg.jl/Pkg.jl/test/registry.jl:290
  Expression: contains(status, "last updated")
   Evaluated: contains("Registry Status \n [23338594] General (https://github.com/JuliaRegistries/General.git)\n    git registry\n", "last updated")
  Stacktrace:
   [1] macro expansion
     @ /opt/hostedtoolcache/julia/nightly/x64/share/julia/stdlib/v1.13/Test/src/Test.jl:741 [inlined]
   [2] (::Main.PkgTestsOuter.PkgTestsInner.RegistryTests.var"#55#56")(depot::String)
     @ Main.PkgTestsOuter.PkgTestsInner.RegistryTests ~/work/Pkg.jl/Pkg.jl/test/registry.jl:290
   [3] (::Main.PkgTestsOuter.PkgTestsInner.Utils.var"#24#25"{Bool, Main.PkgTestsOuter.PkgTestsInner.RegistryTests.var"#55#56"})()
     @ Main.PkgTestsOuter.PkgTestsInner.Utils ~/work/Pkg.jl/Pkg.jl/test/utils.jl:169
   [4] withenv(::Main.PkgTestsOuter.PkgTestsInner.Utils.var"#24#25"{Bool, Main.PkgTestsOuter.PkgTestsInner.RegistryTests.var"#55#56"}, ::Pair{String, Nothing}, ::Vararg{Pair{String, Nothing}})
     @ Base ./env.jl:265
   [5] temp_pkg_dir(fn::Main.PkgTestsOuter.PkgTestsInner.RegistryTests.var"#55#56"; rm::Bool, linked_reg::Bool)
     @ Main.PkgTestsOuter.PkgTestsInner.Utils ~/work/Pkg.jl/Pkg.jl/test/utils.jl:160
   [6] temp_pkg_dir(fn::Function)
     @ Main.PkgTestsOuter.PkgTestsInner.Utils ~/work/Pkg.jl/Pkg.jl/test/utils.jl:141
   [7] top-level scope
     @ ~/work/Pkg.jl/Pkg.jl/test/registry.jl:70
   [8] macro expansion
     @ /opt/hostedtoolcache/julia/nightly/x64/share/julia/stdlib/v1.13/Test/src/Test.jl:1855 [inlined]
   [9] macro expansion
     @ ~/work/Pkg.jl/Pkg.jl/test/registry.jl:284 [inlined]

[GunnarFarneback]

I haven't investigated why it happens yet but I can reproduce it locally.

[GunnarFarneback]

The reason is a not at all obvious interaction between temp_pkg_dir() and download_registries. The test fails when JULIA_PKG_SERVER="", i.e. the package server is not used. temp_pkg_dir() patches DEFAULT_REGISTRIES to symlink General to the copy in the normal depot. Thus download_registries bypasses the code paths which update the update log by symlinking the registry. (This does not happen when using a package server since that overrides the symlinking.)
As a result there is no update date for Registry.status and the test fails.

I could add an update of update log in the symlinking and copying code paths, but it feels somewhat questionable since there's not generally a way for Pkg to update copied registries. On the other hand those installation options are probably almost only used in the tests, so little reason to worry about the update info being misleading.