Indirect Dependency on non-registered Package

Tooling Package Management
1

I want to create unregistered package A.

A depends on unregistered package B which is in the same Git repository as A (monorepo), so this should not be a problem using develop in the package manager.

B depends on the unregistered package C which is in its own git repository. Adding C as a dependency to B was no problem.

However, I get an error when adding B as a dependency for A:

ERROR: Unsatisfiable requirements detected for package C

I couldn’t get this to work in a good way. What I tried or what could work with some other disadvantages:

  • I can add a direct dependency of A on C to make it work. However, this direct dependency is logically wrong
  • I tried adding a [source] section to B’s Project.toml to link to C’s repository with no success. Conceptually, I think adding it to B should work as then all the information should be available for A, but the documentation explicitly states that this information will not be used in A.
  • I tried adding a [source] section to A’s Project.toml to link to C’s repository with no success. All I get is a
ERROR: Sources for `C` not listed in `deps` or `extras` section at "A/Project.toml"
  • Include all our packages, that currently have their own repo, in one large monorepo.This is doable, but as we have some slightly adapted modifications of registered packages (no added features, only some removed features due to licensing issues, so nothing which would make sense to upstream). As we want to stay close to upstream, this would be more difficult without a separate repo.
  • Create our own registry. This is probably doable. But without additional independent users, it seems kind of pointless to track dependencies twice (once in our packages and a second time in our registry).

Any ideas, suggestions, hints?

(adding @kristoffer.carlsson, as I hoped that the feature he presented on JuliaCon 2024 would solve exactly this issue.

2

Create your own registry. This is not so much a question of whether there are outside users but more a question of giving the package manager the information it can work best with.

I’m sure you have heard about the LocalRegistry package, which I have tried to design to make this easy.

The overhead of maintaining a registry can be made very low. At my work it’s completely automated; just bump the version number and merge to master, then CI will take care of the registry.

2 Likes
3

I’d second the use of a LocalRegistry. In my experience, any situation that involves dependencies between more than two unregistered packages is not really manageable in Julia in any sane way. Things might have gotten a little better with the recent addition of the [sources] section in the Project.toml, but I would still recommend all packages that should serve as dependencies for other (unregistered) package to be registered somewhere. Not in the General registry, but somewhere. That’s where LocalRegistry comes in.

I can also confirm that using a LocalRegistry has very little mental overhead.

1 Like