# The present and the future of package registration

**URL:** <https://discourse.julialang.org/t/the-present-and-the-future-of-package-registration/99890>\
**Category:** Package Management\
**Created:** [June 5, 2023, 1:40pm UTC](https://discourse.julialang.org/t/the-present-and-the-future-of-package-registration/99890 "2023-06-05T13:40:11Z")\
**Posts on this page:** 20\
**Page:** 3

<div class="post-metadata">

**Author:** ![lmiq](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/lmiq/32/18314_2.png) [@lmiq](https://discourse.julialang.org/u/lmiq)\
**Post date:** [June 6, 2023, 2:52pm UTC](https://discourse.julialang.org/t/the-present-and-the-future-of-package-registration/99890/41 "2023-06-06T14:52:20Z")

</div>

True, that has another level of complication, if the user names clash. Package committers would rather have to have a “General registry username”, which could be identical to the github username, organization, or not (this is why having at least a feeling that someone likes the idea is necessary to start digging into the details - complications always exist).

---

<div class="post-metadata">

**Author:** ![ericphanson](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/ericphanson/32/215186_2.png) [@ericphanson](https://discourse.julialang.org/u/ericphanson)\
**Post date:** [June 6, 2023, 3:00pm UTC](https://discourse.julialang.org/t/the-present-and-the-future-of-package-registration/99890/42 "2023-06-06T15:00:14Z")

</div>

> [@essenciary](#):
>
> If there is no desire to improve the current system

This isn’t at all specific to your issues, but I think there is _desire_ but what is needed is action.

I think a problem is that lots of people need to use the registry, but only for a very brief period of time that is not core to their work (i.e. they just want to register a package), and that kind of interaction isn’t very conducive to folks moving from user to developer, which happens more often for other open source resources (like packages). So there are very few folks who contribute PRs to RegistryCI, update documentation in General, etc.

---

<div class="post-metadata">

**Author:** ![GunnarFarneback](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/gunnarfarneback/32/1827_2.png) [@GunnarFarneback](https://discourse.julialang.org/u/GunnarFarneback)\
**Post date:** [June 6, 2023, 3:30pm UTC](https://discourse.julialang.org/t/the-present-and-the-future-of-package-registration/99890/43 "2023-06-06T15:30:12Z")

</div>

> [@ToucheSir](#):
>
> Provide some low-friction, easy to access service to check names against the existing registry. Yes there is an automated way to do this using [Automatic merging guidelines · RegistryCI.jl](https://juliaregistries.github.io/RegistryCI.jl/stable/guidelines/#Name-similarity-distance-check), but how many people know to a) look at the RegistryCI docs, b) look at the very bottom of that page to learn about naming guidelines, and c) how to create temporary environments to run the example snippet? Having some easy way to do this with just the stdlib or a hosted web service could avoid many automerge-related complaints in the first place.

One related idea is [Run AutoMerge checks in package · Issue #453 · JuliaRegistries/RegistryCI.jl · GitHub](https://github.com/JuliaRegistries/RegistryCI.jl/issues/453). This is open for grabs for anyone who wants to contribute.

---

<div class="post-metadata">

**Author:** ![goerz](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/goerz/32/3269_2.png) [@goerz](https://discourse.julialang.org/u/goerz)\
**Post date:** [June 6, 2023, 3:33pm UTC](https://discourse.julialang.org/t/the-present-and-the-future-of-package-registration/99890/44 "2023-06-06T15:33:43Z")

</div>

I’m not a maintainer, but I would definitely leave a friendly blocking comment along the lines of “This doesn’t seem quite ready for the General registry yet”. The [official guidelines](https://github.com/JuliaRegistries/General#should-i-register-my-package-now) explicitly mention both documentation and tests and prohibit placeholder packages. I’m not sure how easy that would be to check _automatically_. There has been some talk about adding checks for minimum lines of code and minimum lines in the README or documentation. I would certainly support those, but nobody has gotten around to implementing them. In the meantime, the “human” approach of the community checking what pops up in the new-packages feed seems perfectly fine. That’s exactly why we have the tree day review period for new packages!

I would certainly have raised an eyebrow at `SciMLBase` with an empty README, but probably only left a non-blocking comment, since I know that Chris / SciML isn’t exactly a random person who’s not going to follow up with documentation.

---

<div class="post-metadata">

**Author:** ![ToucheSir](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/touchesir/32/14411_2.png) [@ToucheSir](https://discourse.julialang.org/u/ToucheSir)\
**Post date:** [June 6, 2023, 3:35pm UTC](https://discourse.julialang.org/t/the-present-and-the-future-of-package-registration/99890/45 "2023-06-06T15:35:45Z")

</div>

I think ideally it would be something runnable even before one creates an actual package repo. Maybe something PkgTemplates could help with?

---

<div class="post-metadata">

**Author:** ![goerz](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/goerz/32/3269_2.png) [@goerz](https://discourse.julialang.org/u/goerz)\
**Post date:** [June 6, 2023, 3:36pm UTC](https://discourse.julialang.org/t/the-present-and-the-future-of-package-registration/99890/46 "2023-06-06T15:36:41Z")

</div>

> In any case, there are often packages that are not meant to be used directly by users, and a higher-level interface may be provided by a second package. In such cases, perhaps it’s imposing a rather high standard to expect the “Core” package to be well-documented, especially at the time of merging.

A paragraph in the README “This package provides core functionality for _link to other packages_” would be sufficient then. [I do that myself, exactly.](https://github.com/JuliaQuantumControl/QuantumControlBase.jl#quantumcontrolbase)

---

<div class="post-metadata">

**Author:** ![essenciary](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/essenciary/32/210469_2.png) [@essenciary](https://discourse.julialang.org/u/essenciary)\
**Post date:** [June 6, 2023, 5:11pm UTC](https://discourse.julialang.org/t/the-present-and-the-future-of-package-registration/99890/47 "2023-06-06T17:11:10Z")

</div>

> [@nsajko](#):
>
> No, absolutely no. This would ruin the utility of the General registry and of the concept of a registry in general.

Care to elaborate?

---

<div class="post-metadata">

**Author:** ![Eben60](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/eben60/32/13475_2.png) [@Eben60](https://discourse.julialang.org/u/Eben60)\
**Post date:** [June 6, 2023, 5:17pm UTC](https://discourse.julialang.org/t/the-present-and-the-future-of-package-registration/99890/48 "2023-06-06T17:17:31Z")

</div>

> [@essenciary](#):
>
> 1/ the package creators _should_ do things:

Yes, there _should_ be at least some guaranties for the package quality, and in the most cases nobody but **you** , the package creator, can do the chore of some basic checks.

IMO the registration policy is rather too liberal as it allows (?) to register packages with zero tests and zero documentation.

---

<div class="post-metadata">

**Author:** ![Tamas\_Papp](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/tamas_papp/32/25949_2.png) [@Tamas\_Papp](https://discourse.julialang.org/u/Tamas_Papp)\
**Post date:** [June 6, 2023, 5:29pm UTC](https://discourse.julialang.org/t/the-present-and-the-future-of-package-registration/99890/49 "2023-06-06T17:29:43Z")

</div>

> [@Eben60](#):
>
> the registration policy is rather too liberal as it allows (?) to register packages with zero tests and zero documentation

I cannot disagree with this, but note that it is tricky to design automated checks for these that cannot be easily circumvented.

Either we just rely on simple automated checks, and implicitly the decency of package authors, or we need people to review package registrations.

What I find nice is that even with the very liberal registration policy, abuse of the registry is pretty minimal. This is heartening.

---

<div class="post-metadata">

**Author:** ![Barget](https://avatars.discourse-cdn.com/v4/letter/b/94ad74/32.png) [@Barget](https://discourse.julialang.org/u/Barget)\
**Post date:** [June 6, 2023, 7:02pm UTC](https://discourse.julialang.org/t/the-present-and-the-future-of-package-registration/99890/50 "2023-06-06T19:02:16Z")

</div>

> [@essenciary](#):
>
> If there is no desire to improve the current system, I think it would be of high value to have something like GoLang has, and make Github repos first class citizens - this would allow packages to be registered in General while having unregistered dependencies on Github.

As I understand the situation, the main benefits of the general registry are 1) to “officialize” packages, and 2) to keep them available in the long term. So it increases Julia ecosystem’s robustness.

Having GitHub repos as first-class citizen has some advantages (in particular, to loosen naming requirements), but at the expense of reproducibility. So even if it were a feature, I wouldn’t recommend it for the ecosystem’s main packages (or even for any registered packages).

As a side note, the “first come, first served” phenomenon is so common that I almost take that as a fact of life (and going against is a source of confusion). To illustrate, I have a bad memory of trying desperately to find the right `Proj` library in a Golang project.

---

<div class="post-metadata">

**Author:** ![ToucheSir](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/touchesir/32/14411_2.png) [@ToucheSir](https://discourse.julialang.org/u/ToucheSir)\
**Post date:** [June 6, 2023, 7:10pm UTC](https://discourse.julialang.org/t/the-present-and-the-future-of-package-registration/99890/51 "2023-06-06T19:10:19Z")

</div>

One thing that came up on the Slack thread is that consistency of moderation is also (if not more) important than strength of moderation. e.g. if you have a poorly named package but it passes the similarity check by a hair, you’re home free. I’m not sure precisely how the current automated checks could be improved, but I imagine the Julia community should have no shortage of people who could provide knowledge and expertise in this area.

---

<div class="post-metadata">

**Author:** ![jling](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/jling/32/212909_2.png) [@jling](https://discourse.julialang.org/u/jling)\
**Post date:** [June 6, 2023, 7:24pm UTC](https://discourse.julialang.org/t/the-present-and-the-future-of-package-registration/99890/52 "2023-06-06T19:24:40Z")

</div>

> [@tim.holy](#):
>
> all the important decisions were made by the bot (we don’t know why a human stopped participating in the discussion, but there are many potential explanations

human here, the answer given in the PR (“I’d like to add support for other models in the future”) was sufficient since I just wanted to nudge (hopefully evident by the `[noblock]`) to see if we can avoid unintentional [name squatting](https://users.rust-lang.org/t/name-squatting-on-the-crates-io/42415).

I apologize if I failed to convey the opinion nature of me essentially saying “I THINK everyone could benefit from a less generic name but I’m fine if you think this is fine”

* * *

some historic context. we (was it @ericphanson ?) added the new pkg bot and channel in slack precisely so that everyone in the community can contribute eye ball hours to guard against name squatting. (I have posted the Rust lessons learned many times in Julia community) , and it’s also an excellent way for people to discover what’s happening out there. (again, this is not an instance of name squatting, otherwise, someone would have commented without `[noblock]`.)

---

<div class="post-metadata">

**Author:** ![ericphanson](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/ericphanson/32/215186_2.png) [@ericphanson](https://discourse.julialang.org/u/ericphanson)\
**Post date:** [June 6, 2023, 8:19pm UTC](https://discourse.julialang.org/t/the-present-and-the-future-of-package-registration/99890/53 "2023-06-06T20:19:09Z")

</div>

> [@jling](#):
>
> we (was it @ericphanson ?) added the new pkg bot and channel in slack precisely so that everyone in the community can contribute eye ball hours to guard against name squatting.

I was definitely involved, but I don’t remember if it was my idea or not. I think some of the motivation was additionally to have more visibility into new package registrations to be able help folks understand AutoMerge issues, since it seemed like there were a lot of PRs getting stalled with package author’s not really understanding what AutoMerge wants them to do (e.g. fix compat etc), since often new packages are also new authors (whereas new versions generally come from folks who have registered before).

---

<div class="post-metadata">

**Author:** ![jules](https://avatars.discourse-cdn.com/v4/letter/j/41988e/32.png) [@jules](https://discourse.julialang.org/u/jules)\
**Post date:** [June 7, 2023, 11:57am UTC](https://discourse.julialang.org/t/the-present-and-the-future-of-package-registration/99890/54 "2023-06-07T11:57:01Z")

</div>

Not completely sure if the argument was covered here already, but I sometimes think that the guidelines should discourage names that are too “big” sounding if it’s subjectively hard to deliver on what the name promises. Let’s say you make a package with machine learning utilities, obviously `MachineLearning.jl` would be too big. I’m not saying too imprecise per se, just covering too large an area. Or if you dabble in making tools available to connect to AWS, `AWS.jl` would also be too big unless you plan on really supporting everything and having your package be the go-to thing.

You could argue that you cannot know at registration whether you’ll follow through or not, so I’d say yes, stay away from names that create expectations in users you cannot or don’t intend to fulfill. That’s actually why I often like names like `Makie` or `Genie`, because they are really just names, without many connotations. Compared to, e.g., `Plots.jl` which I think, as has been discussed elsewhere, was too big because now the expectation from new users is that it’s the go-to plotting thing in Julia (historically yes, but nobody decided that it should be). For `Tables.jl`, on the other hand, it seems accurate as it’s a very generic and widespread tool. It’s all very subjective but worth the discussion when controversial names are picked, I think.

---

<div class="post-metadata">

**Author:** ![liuyxpp](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/liuyxpp/32/9870_2.png) [@liuyxpp](https://discourse.julialang.org/u/liuyxpp)\
**Post date:** [June 7, 2023, 12:10pm UTC](https://discourse.julialang.org/t/the-present-and-the-future-of-package-registration/99890/55 "2023-06-07T12:10:47Z")

</div>

Then it would be a nightmare to load packages. Currently, any of my scripts involves at least importing 10+ packages, 30+ sometimes. With all those prefixes, I can not see a line of my actual code in the first page perhaps.

---

<div class="post-metadata">

**Author:** ![kellertuer](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/kellertuer/32/220707_2.png) [@kellertuer](https://discourse.julialang.org/u/kellertuer)\
**Post date:** [June 7, 2023, 1:12pm UTC](https://discourse.julialang.org/t/the-present-and-the-future-of-package-registration/99890/56 "2023-06-07T13:12:20Z")

</div>

This is a very good argument for naming packages. It might, however, also depend on what your aim is. `Optimization.jl` aims to unify as many as possible optimization packages “under one roof”/in one framework. There I think the name is correct. If with `MachineLearning.jl` you aim for the same generality – sure it should have that name.  
If you don’t aim that high and it’s more like `KellertuersPersonalOptim.jl` then maybe fine a name that describes that best (this example. surely does not belong to the good examples). Probably something that describes your own domain best then.

For names that do not have a direct connotation – I feel that might sometimes be a nice “way out” for your specific area in a field or if (like `DrWatson.jl` comes to mind) it is maybe hard to describe in one word or is too clumsy in a single name (maybe `Franklin.jl` is an example here as well).

---

<div class="post-metadata">

**Author:** ![jules](https://avatars.discourse-cdn.com/v4/letter/j/41988e/32.png) [@jules](https://discourse.julialang.org/u/jules)\
**Post date:** [June 7, 2023, 2:00pm UTC](https://discourse.julialang.org/t/the-present-and-the-future-of-package-registration/99890/57 "2023-06-07T14:00:52Z")

</div>

> If with `MachineLearning.jl` you aim for the same generality

Yes I agree, I just believe the number of people actually following through on something of that size is small 🙂 So it’s better to err on the side of longer-less-official-sounding name. Like `MachineLearningUtils.jl` etc. or whatever.

---

<div class="post-metadata">

**Author:** ![kellertuer](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/kellertuer/32/220707_2.png) [@kellertuer](https://discourse.julialang.org/u/kellertuer)\
**Post date:** [June 7, 2023, 2:15pm UTC](https://discourse.julialang.org/t/the-present-and-the-future-of-package-registration/99890/58 "2023-06-07T14:15:16Z")

</div>

You are absolutely right. The task would be quite a huge one to take.

---

<div class="post-metadata">

**Author:** ![goerz](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/goerz/32/3269_2.png) [@goerz](https://discourse.julialang.org/u/goerz)\
**Post date:** [June 7, 2023, 2:44pm UTC](https://discourse.julialang.org/t/the-present-and-the-future-of-package-registration/99890/59 "2023-06-07T14:44:38Z")

</div>

I think very general package names like `MachineLearning` can be great, but I would put quite a lot of scrutiny on them at registration time:

- Does the package already have extensive functionality, complete documentation, and decent test coverage?
- Is there more than one person involved in its development?
- Is it owned a Github organization, rather than a personal account?
- Do the maintainers of the package have a track record?
- Is it backed by some entity with permanent or long-term funding? (A company or academic research group with a tenured PI who can pledge continued support)
- Is someone being paid (at least indirectly) to maintain this package?

Obviously, these are not criteria that can be checked automatically at all.

I would also extend this to things like 3-letter acronym packages. In general, the more general/shorter a name, the more important its quality and long-term prospects. On the other hand, a random PhD student who’s just packaging up their research code, which will probably become unmaintained after they leave academia, should err on the side of long, descriptive package names.

---

<div class="post-metadata">

**Author:** ![ToucheSir](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/touchesir/32/14411_2.png) [@ToucheSir](https://discourse.julialang.org/u/ToucheSir)\
**Post date:** [June 7, 2023, 3:08pm UTC](https://discourse.julialang.org/t/the-present-and-the-future-of-package-registration/99890/60 "2023-06-07T15:08:15Z")

</div>

I agree examples like that deserve scrutiny, but note:

```julia-repl
julia> AutoMerge.meets_distance_check("MachineLearning", all_pkg_names)
(true, "")

```

So if someone did register a package with that name, it would slip through AutoMerge unless someone else caught it on the #new-packages-feed on Slack and managed to take action. Although said Slack channel has caught less-than-optimal names in the past, it’s far from a well-staffed, scalable operation. Say the usual visitors go on vacation at the same time—now we’re back to a problem of inconsistent enforcement.

[Previous page](https://discourse.julialang.org/t/the-present-and-the-future-of-package-registration/99890.md?page=2)

[Next page](https://discourse.julialang.org/t/the-present-and-the-future-of-package-registration/99890.md?page=4)