General

| Workflow | Status | | --------------------------- | ---------------------------------------------------------------------- | | AutoMerge | | | Registry consistency tests | | | TagBot Triggers | | | Update Manifests | |

General is the default Julia package registry. Package registries are used by Julia's package manager [Pkg.jl][pkg] and includes information about packages such as versions, dependencies and compatibility constraints.

The General registry is open for everyone to use and provides access to a large ecosystem of packages.

If you are registering a new package, please make sure that you have read the [package naming rules][naming-guidelines].

Follow along new package registrations with the #new-packages-feed channels in the community Slack or Zulip!

See our Contributing Guidelines for ways to get involved!

Registering a package in General

New packages and new versions of packages are added to the General registry by pull requests against this GitHub repository. It is highly recommended that you use [Registrator.jl][registrator] to automate this process. Registrator can either be used as a [GitHub App][registrator-app] or through a [web interface][registrator-web], as described in the [Registrator README][registrator-readme].

When Registrator is triggered a pull request is opened against this repository. Pull requests that meet certain guidelines are merged automatically, see Automatic merging of pull requests. Other pull requests need to be manually reviewed and merged by a human.

It is highly recommended to also use [TagBot][tagbot], which automatically tags a release in your repository after the new release of your package is merged into the registry.

Registered packages MUST have an Open Source Initiative approved license, clearly marked via the license file (see below for definition) in the package repository. Packages that wrap proprietary libraries (or otherwise restrictive libraries) are acceptable if the licenses of those libraries permit open source distribution of the Julia wrapper code. The more restrictive license of the wrapped code:

1. MUST be mentioned in either the third party notice file or the license file (preferably the third party notice file).
2. SHOULD be mentioned in the README file.

Please note that:

• "README file" refers to the plain text file named README.md, README, or something similar.
• "License file" refers to the plain text file named LICENSE.md, LICENSE, COPYING, or something similar.
• "Third party notice file" refers to the plain text file named THIRD_PARTY_NOTICE.md, THIRD_PARTY_NOTICE, or something similar.

Automatic merging of pull requests

Pull requests that meet certain criteria are automatically merged periodically. Only pull requests that are opened by [Registrator][registrator] are candidates for automatic merging.

The full list of AutoMerge guidelines is available in the [RegistryCI documentation][automerge-guidelines].

Please report issues with automatic merging to the [RegistryCI repo][registryci].

Currently the waiting period is as follows:

• New Julia packages: 3 days (this allows time for community feedback)
• New versions of existing packages: 15 minutes
• JLL package (binary dependencies): 15 minutes, for either a new package or a new version

FAQ

Do I need to register a package to install it?

No, you can simply do using Pkg; Pkg.add(url="https://github.com/JuliaLang/Example.jl") or ] add https://github.com/JuliaLang/Example.jl in the Pkg REPL mode to e.g. install the package Example.jl, even if it was not registered. When a package is installed this way, the URL is saved in the Manifest.toml, so that file is needed to resolve Pkg environments that have unregistered packages installed.

Registering allows the package to be added by Pkg.add("Example") or ] add Example in the Pkg REPL mode. This is true if the package is installed in any registry you have installed, not just General; you can even create your own registry!

Should I register my package now?

If your package is at a stage where it might be useful to others, or provide functionality other packages in General might want to rely on, go for it!

We ask that you consider the following best practices.

• It is easier for others to use your package if it has documentation that explains what the package is for and how to use it. This could be in the form of a README or hosted documentation such as that generated by Documenter.jl.
• And in order to provide reliable functionality for your users, it is also important to setup tests (see the Pkg.jl docs and the Test stdlib docs), which can be automatically run by free continuous integration services such as GitHub Actions. As part of the test suite, tools like Aqua.jl and JET.jl can help you remove bugs or typos and improve the general quality of your code.

Packages like PkgTemplates.jl or PkgSkeleton.jl provide easy ways to setup documentation, tests, and continuous integration.

Some types of packages should not be registered, or are not yet ready for registration:

• The General registry is not a place for "personal packages" that consist of collections of "utility functions" nor for packages that are only useful for a closed group (like a research group or a company). For that, it is easy to set up your own registry using for example LocalRegistry.jl. The Pkg documentation about registries might be useful if you decide to go this route.
• Packages that are "vibe-coded" (generated by an LLM without human review) are not suitable for registration. See the LLM policy.
• "Empty" packages that do not yet have functionality are not ready to be registered.

Is there any policy regarding the use of LLM's in registered packages?

It is perfectly fine to register packages that have been produced with the assistance of a large language model (LLM) such as Claude Code or any similar tool. However, it is essential that a human maintainer has a full understanding of the generated code.

It is not okay to submit vibe-coded packages, defined as "building software with an LLM without reviewing the code it writes". Packages that exhibit obvious signs of "AI slop" may be blocked from registration. To ensure that a package containing LLM-generated components is suitable for this registry, follow best practices as much as possible:

• If your package contains substantial contributions from a generative AI tool, please disclose so with details in the README.
• Review and understand all generated code, by hand.
• Avoid lengthy, verbose, and over-selling READMEs; review and trim down any documentation generated by an LLM. Being concise is a community value.
• Ensure that the code is tested and that these tests run in continuous integration (CI), such as GitHub Actions. Collect and track coverage information.
• Build and deploy documentation in CI, using a system like Documenter.jl where appropriate.

When communicating about a package registration, make sure to express your own thoughts and ideas. Don't rely on an LLM to think for you. We want to hear from you! Occasionally, folks will copy feedback on a registration directly into an LLM that doesn't have the context or understanding to reply accurately; please don't do this.

Can my package in this registry depend on unregistered packages?

No. In this registry, your package cannot depend on other packages that are unregistered. In addition, your package cannot depend on an unregister