General Julia Registry

The General registry is a shared community resource, not a curated list. Users should be aware of the following:

• No Scrutiny: Packages in the General registry are not reviewed or scrutinized by maintainers.
• Not Official: Packages are not "official" and are not endorsed or approved by the JuliaLang organization.
• User Responsibility: The registry and its maintainers are not responsible for the code you install. You are responsible for reviewing your own code dependencies.

Pull requests (PRs) opened by Registrator.jl that meet specific criteria are eligible for automatic merging. Other PRs require manual review by a human.

Waiting periods for AutoMerge:

• New Julia packages: 3 days (to allow for community feedback).
• New versions of existing packages: 15 minutes.
• JLL packages (binary dependencies): 15 minutes (for both new packages and new versions).

If you encounter issues with automatic merging, report them to the RegistryCI repository.

Using LLMs (like Claude Code) for assistance is permitted, but the following rules apply:

• Human Oversight: A human maintainer must fully understand and review all generated code. 'Vibe-coded' packages (LLM-generated without review) are prohibited.
• Disclosure: If a package contains substantial generative AI contributions, disclose this in the README.
• Documentation Quality: Avoid verbose, over-selling READMEs generated by LLMs; keep documentation concise.
• Testing: Ensure all LLM-generated components are thoroughly tested and covered by CI.
• Communication: Do not use LLMs to respond to registration feedback; maintainers expect human thoughts and ideas.

All binary artifacts in the General registry and Yggdrasil are redistributed through the Julia Pkg servers. Consequently, the Julia community must have the necessary permissions to redistribute these artifacts.

• Permission Requirement: If a proprietary binary artifact cannot be redistributed via Pkg servers, it is not permitted in the General registry or Yggdrasil.
• License Compliance: If a registered binary artifact is found to lack a license permitting redistribution, it will be yanked from the General registry and Yggdrasil unless the rightsholder grants explicit permission.

Packages in the General registry must follow strict dependency rules to ensure reproducibility:

• No Unregistered Dependencies: A registered package cannot depend on any unregistered packages.
• No Unregistered Versions: A registered package cannot depend on an unregistered version of a package that is otherwise registered.

If a release is broken or has security vulnerabilities, you can mark it as "yanked".

How to yank: Add yanked = true under the release entry in Versions.toml.

Behavior:

• Pkg.add() and Pkg.resolve() will no longer select yanked versions.
• Yanked versions still work in existing Manifest.toml files via Pkg.instantiate().
• Yanked versions cannot be re-registered with different source code.

Note: For security vulnerabilities (malicious code), yanking is insufficient; the release should be deleted from the registry and a new patch issued.

Moving to a Subdirectory

1. Move files using git (preserving history).
2. Submit a manual PR to the General registry adding a subdir field to the package's Package.toml.
3. Ensure a copy of the license file is in the subdirectory.

Moving a Subdirectory Package to its own Repository

1. Use git-filter-repo with the --subdirectory-filter flag to split the folder into a new repo. Important: Do not use --path as it changes the root tree SHA, which breaks registry entries.
2. Verify the new repo contains all registered versions.
3. Submit a manual PR to the General registry to edit the Package.toml and remove the subdir line.

AutoMerge checks if a package can be installed and loaded. If your package requires proprietary software to function, it may fail this check. To allow registration without manual intervention, you can check for the JULIA_REGISTRYCI_AUTOMERGE environment variable in your package's load logic:

if isdefined(ENV, "JULIA_REGISTRYCI_AUTOMERGE") && ENV["JULIA_REGISTRYCI_AUTOMERGE"] == "true"
    # Logic to make the package loadable even without proprietary software
end

Renaming an Unregistered Package

1. Rename the GitHub repository to NewName.jl.
2. Rename src/OldName.jl to src/NewName.jl.
3. Rename the top-level module to NewName.
4. Update Project.toml package name to NewName.
5. Update tests and documentation.
6. Retrigger registration.

Renaming a Registered Package

Registration is permanent, so you must re-register the package as a new entity:

1. Follow the renaming steps above.
2. Create a PR to edit the registry's URL for the old package name to point to the new URL (to keep old versions working).
3. Generate a new UUID for Project.toml.
4. Increment the version in Project.toml (this is a breaking change).
5. Register it as a new package and comment on the PR that it is a rename.

Before registering a package in the General registry, ensure it meets these quality standards:

• Documentation: Provide a README or hosted documentation (e.g., via Documenter.jl).
• Testing: Implement a test suite and run it via Continuous Integration (CI) like GitHub Actions. Tools like Aqua.jl and JET.jl are recommended for improving code quality.
• Avoid 'Personal' Packages: The General registry is not for utility functions used only by a specific group or company. For private/internal use, consider setting up a local registry using LocalRegistry.jl.
• No 'Vibe-coding': Packages generated by LLMs without human review are not suitable for registration.
• No 'Empty' Packages: Packages must have actual functionality before registration.