What kind of packages can be accepted by Julia community?

What are the necessary conditions for a Julia package to be accepted and registered as a public package in the Julia community? In other words, what is the level of threshold for a Julia package to be successfully registered? Is there a requirement for the amount of code? Must advanced programming syntax be used? Does the functionality implemented need to be unique? In essence, how tolerant is the Julia community towards registering a package?

Thanks in advance!

1 Like

Read through this:

But basically there are no requirements on the content of the package, if you think it’s useful for others then go ahead and register (after reading the above)


As an example of the above guide: recently, DifferentiationInterface, a self-described “interface to various automatic differentiation (AD) backends in Julia” was registered, despite the existence of AbstractDifferentiation.

To register it, a discussion between authors of both packages occurred and the similarities and differences of goals and implementation were clarified.

Beyond these differences (and not at all referring to the above discussion) sometimes people just don’t want to work together, and that’s also a fine reason to have separate packages (although a disappointing one).


I think it is important to not conflate “accepted by the Julia community” with “registered in the general registry Registry.jl”. These two are not identical.

There are community members that are unsatisfied with the low (some would even say non existent) quality threshold a package has to cross to be registered in the general registry. Others instead say that there should be no quality control and everything should be in the general registry, in essence establishing that the general registry can make no statements regarding usefulness or adoption of contained packages. In my view we are currently in this scenario.

What best answers “what can be accepted” is by answering “what will be used”: if a package is useful for a meaningful portion of the Julia community, it will be downloaded and used. If not, it won’t be. And in my experience for a package to succeed in that it needs to have some amount of code, and some amount of documentation, and some amount of unique functionality that doesn’t exist in an already adopted package. Advanced programming practices are definitely not necessary.


I would reiterate my comment from an older, similar thread:

The threshold for registration is pretty low. It has to have some amount of non-trivial functionality to be “useful” (whatever that means, but it can’t be an empty “Hello World” placeholder). And it has to have some documentation (at least a README). Basically, looking at the repository, an average Julia user should be able to figure out what the package does and have a rough idea how to use it.

Anything beyond that is on a case-by-case basis. The package name can be a pretty important issue: it should somewhat accurately reflect the scope of the project. The more general/short the package name, the more scrutiny it would probably receive. Like, if someone wanted to register MachineLearning.jl, I’d expect that to be a bit more mature, have full documentation, and have a team behind it that can commit to long-term maintenance. With a long, descriptive package name, you can get pretty much anything registered, no questions asked.

So there are almost no “necessary conditions”. But also, anyone in the community can block a registration, so we rely on informal common-sense norms. Things that have a strong consensus typically get formalized in the Package Naming Guidelines and the General Registry FAQ. Ultimately, there is a small set of registry maintainers that have the last word, in that they can manually merge registrations, overriding any blocking comments.