Circular dependency with Accessors 0.1.40 and julia 1.10

[lcontento]

When installing the latest Accessors 0.1.40 on julia 1.10 I get a circular dependency warning

┌ Warning: Circular dependency detected. Precompilation will be skipped for:
│   DatesExt [0361c7f5-3687-5641-8bd2-a1de0c64d1ed]
│   LinearAlgebraExt [ef8e1453-9c17-56fe-886b-405471570bc8]

It gives no warning on julia 1.11 or installing Accessors 0.1.39 (whose project is a bit different but not substantially so from 0.1.40). Maybe it is an upstream bug in julia 1.10?

[ranocha]

I can confirm this. It becomes much worse if you add additional packages, e.g.,

pkg> add Accessors@0.1.40 OrdinaryDiffEq

gives

┌ Warning: Circular dependency detected. Precompilation will be skipped for:
│   OrdinaryDiffEqExplicitRK [9286f039-9fbf-40e8-bf65-aa933bdc4db0]
│   BracketingNonlinearSolve [70df07ce-3d50-431d-a3e7-ca6ddb60ac1e]
│   NonlinearSolveFirstOrder [5959db7a-ea39-4486-b5fe-2dd0bf03d60d]
│   NonlinearSolveBaseSparseMatrixColoringsExt [e3ecd195-ca82-5397-9546-f380c1e34951]
│   OrdinaryDiffEqCore [bbf590c4-e513-4bbe-9b18-05decba2e5d8]
│   SciMLOperatorsStaticArraysCoreExt [a2df0a61-553a-563b-aed7-0ce21874eb58]
│   DiffEqBaseChainRulesCoreExt [b00db79b-61e3-50fb-b26f-2d35b2d9e4ed]
│   NonlinearSolve [8913a72c-1f9b-4ce2-8d82-65094dcecaec]
│   OrdinaryDiffEq [1dea7af3-3e70-54e6-95c3-0bf5283fa5ed]
│   OrdinaryDiffEqCoreEnzymeCoreExt [ca1c724a-f4aa-55ef-b8e4-2f05449449ac]
│   RecursiveArrayToolsFastBroadcastExt [42296aa8-c874-5f57-b5c1-8d6f5ebd5400]
│   SciMLBase [0bca4576-84f4-4d90-8ffe-ffa030f20462]
│   NonlinearSolveBaseForwardDiffExt [63d416d0-6995-5965-81e0-55251226d976]
│   OrdinaryDiffEqPDIRK [5dd0a6cf-3d4b-4314-aa06-06d4e299bc89]
│   LineSearchLineSearchesExt [8d20b31a-8b56-511a-b573-0bef60e8c8c7]
│   NonlinearSolveQuasiNewton [9a2c21bd-3a47-402d-9113-8faf9a0ee114]
│   RecursiveArrayToolsSparseArraysExt [73e54eaf-3344-511d-b088-1ac5413eca63]
│   OrdinaryDiffEqHighOrderRK [d28bc4f8-55e1-4f49-af69-84c1a99f0f58]
│   SimpleNonlinearSolveDiffEqBaseExt [904f2055-56f7-5591-b06b-453cba458f4b]
│   OrdinaryDiffEqLowStorageRK [b0944070-b475-4768-8dec-fb6eb410534d]
│   OrdinaryDiffEqStabilizedRK [358294b1-0aab-51c3-aafe-ad5ab194a2ad]
│   OrdinaryDiffEqSymplecticRK [fa646aed-7ef9-47eb-84c4-9443fc8cbfa8]
│   OrdinaryDiffEqStabilizedIRK [e3e12d00-db14-5390-b879-ac3dd2ef6296]
│   OrdinaryDiffEqSSPRK [669c94d9-1f4b-4b64-b377-1aa079aa2388]
│   OrdinaryDiffEqLowOrderRK [1344f307-1e59-4825-a18e-ace9aa3fa4c6]
│   OrdinaryDiffEqFunctionMap [d3585ca7-f5d3-4ba6-8057-292ed1abd90f]
│   OrdinaryDiffEqExponentialRK [e0540318-69ee-4070-8777-9e2de6de23de]
│   LinearSolveEnzymeExt [133222a9-3015-5ee0-8b28-65fc8ed13c28]
│   OrdinaryDiffEqLinear [521117fe-8c41-49f8-b3b6-30780b3f0fb5]
│   OrdinaryDiffEqDifferentiation [4302a76b-040a-498a-8c04-15b101fed76b]
│   NonlinearSolveBaseSparseArraysExt [8494477e-8a74-521a-b11a-5a22161b1bc8]
│   LinearSolveRecursiveArrayToolsExt [04950c4b-5bc4-5740-952d-02d2c1eb583a]
│   SciMLJacobianOperators [19f34311-ddf3-4b8b-af20-060888a46c0e]
│   NonlinearSolveBaseLineSearchExt [a65b7766-7c26-554a-8b8d-165d7f96f890]
│   OrdinaryDiffEqNonlinearSolve [127b3ac7-2247-4354-8eb6-78cf4e7c58e8]
│   SparseDiffToolsPolyesterExt [9f049cbb-7c7d-5dfe-91f7-cf323d5306ff]
│   OrdinaryDiffEqTsit5 [b1df2697-797e-41e3-8120-5422d3b24e4a]
│   OrdinaryDiffEqSDIRK [2d112036-d095-4a1e-ab9a-08536f3ecdbf]
│   LinearAlgebraExt [ef8e1453-9c17-56fe-886b-405471570bc8]
│   LineSearch [87fe0de2-c867-4266-b59a-2f0a94fc965b]
│   TestExt [62af87b3-b810-57d2-b7eb-8929911df373]
│   OrdinaryDiffEqBDF [6ad6398a-0878-4a85-9266-38940aa047c8]
│   SciMLBaseChainRulesCoreExt [4676cac9-c8e0-5d6e-a4e0-e3351593cdf5]
│   OrdinaryDiffEqExtrapolation [becaefa8-8ca2-5cf9-886d-c06f3d2bd2c4]
│   OrdinaryDiffEqVerner [79d7bb75-1356-48c1-b8c0-6832512096c2]
│   NonlinearSolveBaseLinearSolveExt [3d4538b4-647b-544e-b0c2-b52d0495c932]
│   StaticArraysExt [6207fee4-2535-5e24-a3ba-6518da1c7d2a]
│   SimpleNonlinearSolveChainRulesCoreExt [073a8d7d-86ee-5d75-9348-f9bf6155b014]
│   OrdinaryDiffEqNordsieck [c9986a66-5c92-4813-8696-a7ec84c806c8]
│   SparseDiffTools [47a9eef4-7e08-11e9-0b38-333d64bd3804]
│   OrdinaryDiffEqPRK [5b33eab2-c0f1-4480-b2c3-94bc1e80bda1]
│   OrdinaryDiffEqDefault [50262376-6c5a-4cf5-baba-aaf4f84d72d7]
│   OrdinaryDiffEqFIRK [5960d6e9-dd7a-4743-88e7-cf307b64f125]
│   OrdinaryDiffEqRKN [af6ede74-add8-4cfd-b1df-9a4dbb109d7a]
│   BracketingNonlinearSolveForwardDiffExt [bb716554-e89b-5af4-bfb6-0f88eb8bb218]
│   NonlinearSolveSpectralMethods [26075421-4e9a-44e1-8bd1-420ed7ad02b2]
│   SciMLOperators [c0aeaf25-5076-4817-a8d5-81caf7dfa961]
│   NonlinearSolveBaseDiffEqBaseExt [a0bd8381-04c7-5287-82b0-0bf1e59008be]
│   RecursiveArrayTools [731186ca-8d62-57ce-b412-fbd966d074cd]
│   SimpleNonlinearSolve [727e6d20-b764-4bd8-a329-72de5adea6c7]
│   OrdinaryDiffEqRosenbrock [43230ef6-c299-4910-a778-202eb28ce4ce]
│   NonlinearSolveBase [be0214bd-f91f-a760-ac4e-3421ce2b2da0]
│   OrdinaryDiffEqIMEXMultistep [9f002381-b378-40b7-97a6-27a27c83f129]
│   OrdinaryDiffEqFeagin [101fe9f7-ebb6-4678-b671-3a81e7194747]
│   LinearSolve [7ed4a6bd-45f5-4d41-b270-4a48e9bafcae]
│   OrdinaryDiffEqQPRK [04162be5-8125-4266-98ed-640baecc6514]
│   SymbolicIndexingInterface [2efcf032-c050-4f8e-a9bb-153293bab1f5]
│   DatesExt [0361c7f5-3687-5641-8bd2-a1de0c64d1ed]
│   RecursiveArrayToolsForwardDiffExt [14203109-85fb-5f77-af23-1cb7d9032242]
│   SciMLOperatorsSparseArraysExt [9985400b-97ec-5583-b534-4f70b643bcf7]
│   OrdinaryDiffEqAdamsBashforthMoulton [89bda076-bce5-4f1c-845f-551c83cdda9a]
│   DiffEqBaseSparseArraysExt [4131c53f-b1d6-5635-a7a3-57f6f930b644]
│   DiffEqBase [2b5f629d-d688-5b77-993f-72d75c75574e]
└ @ Pkg.API ... julia/stdlib/v1.10/Pkg/src/API.jl:1279

[devmotion]

The upcoming 1.10.8 might solve these warnings: JuliaLang/julia#52511 (comment)

[mestinso]

Ran into this today. Any best practice suggestions as a workaround (assuming it's an upstream bug)? Should julia 1.10 users just pin Accessors to 0.1.39?

[aplavin]

This is definitely an upstream Julia bug, but I somehow thought it's fixed already... Apparently, not.
Note that this shouldn't influence the actual behavior, AFAIK these warnings are harmless.

Earlier, we worked around this by reverting weakdeps making them regular deps. I guess that's what I can do soon (unless others get to it earlier).

[ranocha]

Note that this shouldn't influence the actual behavior, AFAIK these warnings are harmless.

Given the warning

Precompilation will be skipped

in the error message, the issue will likely introduce a lot of latency, won't it?

[IanButterworth]

I built the tip of the backports-release-1.10 branch (what's being prepared for 1.10.8) and still found circularity (but note the message is clearer now)

┌ Warning: Circular dependency detected.
│ Precompilation will be skipped for dependencies in this cycle:
│  ┌ Accessors → LinearAlgebraExt
│  └─ Accessors → DatesExt
│ Precompilation will also be skipped for the following, which depend on the above cycle:
│   Transducers
│   Accessors → StructArraysExt
│   BangBang → BangBangStaticArraysExt
│   BangBang → BangBangDataFramesExt
│   BangBang → BangBangChainRulesCoreExt
│   Flux
│   Transducers → TransducersDataFramesExt
│   Transducers → TransducersAdaptExt
│   Accessors → TestExt
│   ObjectDetector
│   Accessors → IntervalSetsExt
│   Accessors → StaticArraysExt
│   FLoops
│   BangBang
│   BangBang → BangBangStructArraysExt
│   MLDataDevices → MLDataDevicesMLUtilsExt
│   MicroCollections
│   BangBang → BangBangTablesExt
│   MLUtils
└ @ Pkg.API.Precompilation ~/Documents/GitHub/julia/usr/share/julia/stdlib/v1.10/Pkg/src/precompilation.jl:584

[devmotion]

But... there's actually no cycle, if I'm not mistaken? So this means there are still unfixed bugs in the 1.10 branch?

[IanButterworth]

The issue is that Dates and LinearAlgebra are in the default julia sysimage, thus are always loaded, so their exts are always triggered, which creates the cycle.

On 1.11 this is avoided and 1.12 extensions are triggered by importing packages, not just whether they're loaded. (IIUC, @topolarity)

[devmotion]

On 1.11 this is avoided

Is it possible to backport this fix to 1.10?

[aplavin]

Could anyone please confirm if #193 is the correct and complete solution?
And should we expect to be able to make Dates + LA weakdeps in 1.10 in the future?

[mestinso]

Could anyone please confirm if #193 is the correct and complete solution? And should we expect to be able to make Dates + LA weakdeps in 1.10 in the future?

Ran a quick test in both 1.10 and 1.11: added and precompiled without issue.