Costs of registering packages

The guidance for the general registry ends:

So, if for any reason including a package in the general registry was not advisable
(discouraged?), the registering users would be responsible for not proceeding; the registry
has no automatic or manual means of enforcing that. At least, that is my interpretation.

Packages that are not registered can also be reproducible with appropriate use of a version control system (e.g., git). Registering the package records the git hash and repo URL associated with each released version. But, that doesn’t have to be done with the Julia registry.

Well, there is more going on: All registered packages are stored in a caching server, so even if my git server is turned off they will still be available…

OK, I think I learnt a few things:
a. It is possible to register packages which should not have been registered. There is very little gatekeeping in place.
b. Only one “cost” had been mentioned: filling up the namespace. But it isn’t clear what that really means.
c. There was no mention of concerns regarding energy use, storage, or communication (such as slowing down the work with the registry). That is interesting.

Regarding point b: I nearly registered the package GitHub - ufechner7/Rubi.jl: Symbolic, rule based integration in Julia

Luckily I did not do it, I do not have the time to make it work, it is just a skeleton.
If I would have registered it I could not give back the name.

And regarding point c: Try to find a sustainable engineering student to investigate this!

Yes, every new package and new version adds to the size of the registry, with consequences for storage, network downloads, and speed of version resolution. It’s easy enough to measure how much the size increases by adding a new package but the general thinking is that it’s small enough to be worth it to get new packages and new versions. But it also won’t scale to millions of packages with the current setup.

1 Like