Inter-registry dependencies

Current registry design does not allow to register packages that have dependencies registered in other registries. This limitation is circumvented for any package registered in General registry because this registry is the default one. I believe it was done intentionally because the multi-registry design was created primarily to support “walled garden” rather then naming encapsulation.

So, is it possible to remove such limitation?

The only limitation right now (AFAIK) is that you need to have the registries available on your system before you add the package. Other than that, there isn’t any technical issue with having dependencies that are registered in other registries.

1 Like

Invenia’s private registry has hundreds of dependencies on things registered in General.

Assuming that I what to install a package from the private registry, and I know a registry location which I add to the package manager prior to installation. Now, I install a package and it happens to have a dependency that registered in another registry, that I am not aware of. In order to successfully install a package, I need to collect information about all possible registries from where dependencies came, and make this information available to the package manager.

When I refer to a design limitation, it’s the limitation in the registry format that does not allow connectivity between various registries, and subsequent dependency on manual information discovery process.

As I mentioned, General registry has a privileged position as it’s information hard-coded in every Julia installation. Remove General registry from the package manager, and you won’t be able to install any package from Invenia’s registry that has dependency on General’s packages.

I am developing a package that I would like to add to the main Julia registry, but my package depends on another package that is in a personal (but public) registry:

Is there a way to set up my package’s Project.toml to refer to the other package in this other registry so that CI etc. will work?
If not, are there any other options, other than duplicating the relevant code from that other package in my own (with attribution of course) which seems like a last resort…

Apologies if this is off topic; it seemed like the most related post in this category.

That does not work. Packages registered in the General registry can only depend on other packages registered in the General registry.

2 Likes