In a few recent threads there are discussions about the appropriateness of tiny packages with trivial code in the General registry. Those threads started discussing specific cases of packages that only have a couple of simple, small functions, or that the only thing they do is reexporting a bunch of modules from the stdlib and other packages.
I was reading the arguments, which in their majority discourage the registration of such packages. As a very coarse and amalgamated summary of those arguments, Iād say that the reasons for such discouragement is that:
- a registry widely populated by packages like those might become chaotic and brittle; and
- it increases the probability of āgood namesā being taken by packages that are not that much relevant.
Those are good reasons, although @StefanKarpinskiās comment in one of those threads implies that there are means to soothe the impact of those problems (i.e. irrelevant or unmaintained packages can be detected an archived, and name duplicity is manageable).
On the other hand, there is a point in developing such tiny packages, specially if both types (packages with trivial functionalities, and packages that put together other packages) are considered. That is a perfectly fine way of making bigger packages incrementally. Actually, sometimes I have read people encouraging others to create such small packages when there is a proposal to incorporate some new functionality, instead of directly making a PR to Julia.
So, I think that the question is not whether those packages are āgood enoughā or not in general terms ā Iād say they are, but whether they belong in the General registry. This is my take on this question:
- If your small package is something very experimental, not yet to be used in production, and what you want is that people test it and give feedback, donāt register yet. Probably there is no point in keeping those exploratory versions available to be easily
add-ed in the future, itāll be easier to rename it, less remorse if you eventually abandon it, etc. - On the other hand, if the package is so simple that you think that it might live forever as it is, regardless of changes in the Julia ecosystem, etc., donāt register it either. The only interaction of the package manager with your package should be
addit orremoveit. Thatās fine with an URL. - Now, if the package has dependencies that may break as soon as they have significant changes, or the package itself may experiment changes that could break the usersā code, then do register, so that updates can be dealt with wisely by the package manager.
(Note: Iām assuming here that registered packages can depend on unregistered ones, but Iām not sure. If it is not like that, then case #2 can be ādo registerā too).
I think these are general rules of thumb, no matter whether the package is small or big. Only that tiny packages are more likely to fall in the first two cases.
An additional reason why developers may want to have their packages registered, even if they donāt need to, is because that will make them easier to discover by search engines based on the registry (e.g. Juliahub, Julia Packagesā¦). But at least the latter uses other sources, so for instance popular packages in Github should also be found, registered or not.