What happens if two packages require each other?

General Usage
1

Has this chicken & the egg problem already been resolved?

edit: for clarity, this could be:

  • shallow mutual requiring ( a deps on b && b deps on a )
  • or requiring each other through some intermediary packages ( a deps on b deps on c deps on a )
2

A “base” package required by both packages should do the trick. It would have the minimal set of code that is needed by the other packages.

3 Likes
3

Just found an example…

So we’re clear, there’s nothing to worry about?

// I’m probably going to hide it on my website otherwise

see below: AWSLambda.jl requires itself (indirectly)

3360Ă—2100 538 KB

4

Circular dependencies may confuse a few scripts people write if they don’t take into account the possibility they might happen, but Pkg doesn’t have any problems with them. It might hit some corner cases in precompilation, hard to tell unless anyone finds an issue.

1 Like
5

Sounds good. Thanks for looking into it!

Some more info before closing this:

Currently AWSLambda and AWSSNS are the only packages with circular dependencies.

Regardless,

  • I now hide circular dependencies on the site
  • but print them all to the logs every data update
6

Is it still true that packages are allowed to depend on one another in Julia/Pkg v1.5.3+?

I’m maintaining some private registries for my work, and we need these packages to behave as “nodes” in a closed-loop feedback system. For example, the output of Package A feeds into Package B feeds into Package C feeds back into Package A. Or, alternatively, Package A depends on B depends on C depends on A.

Perhaps there’s a better way to reorganize things, but for the time being Julia/Pkg returns “AssertionError: sourcepath !== nothing” when I run “pkg> instantiate” on Package A, B or C in this example. I’ve been noticing people saying that Julia/Pkg doesn’t (or shouldn’t) support circular dependencies, but at least in my case I feel like it’s more a feature than a bug.

Any updates on this would be great, thank you!

7

I would feel uncomfortable with a circular dependency setup for that, even if it would work. E.g. separating out the loop into a project that depends on all the others seems possible.

Alternatively, or if the loop is the materialization of some general “lifecycle”, then I would create the lifecycle package as the “root” without any dependencies. A, B and C would depend only on the lifecycle package (getting input from it and providing output, by implementing an interface), and the system would be assembled in a project that depends on all of them.

1 Like
8

Yeah, this is something I’ve been afraid I’d need to accept sooner or later, but I think you’re 100% correct that it’s just better to reorganize things. There’s a difference between project dependencies (i.e. what Julia/Pkg manages) and data input/output dependencies, which until now I’ve been basically conflating.

9

I haven’t tried, but I believe it’s still allowed. As you’ve already concluded though, it’s best to avoid.

10

So, it’s kind of inconsistent to me at least - I get that sourcepath !== nothing assertion error when I run pkg> instantiate, but if I try pkg> update my project dependencies seem to shake out alright (including getting downloaded).

For reference, I’m seeing this kind of error: https://github.com/JuliaLang/Pkg.jl/issues/2097

And the “offending” line producing that AssertionError is here: https://github.com/JuliaLang/Pkg.jl/blob/becccb374edaccb662b106c305a77b1db4a64079/src/Operations.jl#L1665

For context, here is my Julia setup:

julia> versioninfo()
Julia Version 1.5.3
Commit 788b2c77c1 (2020-11-09 13:37 UTC)
Platform Info:
  OS: Windows (x86_64-w64-mingw32)
  CPU: Intel(R) Core(TM) i7-8700 CPU @ 3.20GHz
  WORD_SIZE: 64
  LIBM: libopenlibm
  LLVM: libLLVM-9.0.1 (ORCJIT, skylake)