back to home

JuliaRegistries / General

The official registry of general Julia packages

696 stars
546 forks
120 issues
JuliaShell

AI Architecture Analysis

This repository is indexed by RepoMind. By analyzing JuliaRegistries/General in our AI interface, you can instantly generate complete architecture diagrams, visualize control flows, and perform automated security audits across the entire codebase.

Our Agentic Context Augmented Generation (Agentic CAG) engine loads full source files into context on-demand, avoiding the fragmentation of traditional RAG systems. Ask questions about the architecture, dependencies, or specific features to see it in action.

Source files are only loaded when you start an analysis to optimize performance.

Embed this Badge

Showcase RepoMind's analysis directly in your repository's README.

[![Analyzed by RepoMind](https://img.shields.io/badge/Analyzed%20by-RepoMind-4F46E5?style=for-the-badge)](https://repomind.in/repo/JuliaRegistries/General)
Preview:Analyzed by RepoMind

Repository Overview (README excerpt)

Crawler view

General | Workflow | Status | | --------------------------- | ---------------------------------------------------------------------- | | AutoMerge | [![AutoMerge status][AutoMerge-img]][AutoMerge-url] | | Registry consistency tests | [![Registry consistency tests][CI-img]][CI-url] | | TagBot Triggers | [![TagBot Triggers status][TagBotTriggers-img]][TagBotTriggers-url] | | Update Manifests | [![Update Manifests status][UpdateManifests-img]][UpdateManifests-url] | [AutoMerge-url]: https://github.com/JuliaRegistries/General/actions/workflows/automerge.yml [AutoMerge-img]: https://github.com/JuliaRegistries/General/actions/workflows/automerge.yml/badge.svg "AutoMerge status" [CI-url]: https://github.com/JuliaRegistries/General/actions/workflows/registry-consistency-ci.yml [CI-img]: https://github.com/JuliaRegistries/General/actions/workflows/registry-consistency-ci.yml/badge.svg?branch=master "Registry consistency tests" [TagBotTriggers-url]: https://github.com/JuliaRegistries/General/actions/workflows/TagBotTriggers.yml [TagBotTriggers-img]: https://github.com/JuliaRegistries/General/actions/workflows/TagBotTriggers.yml/badge.svg "TagBot Triggers status" [UpdateManifests-url]: https://github.com/JuliaRegistries/General/actions/workflows/update_manifests.yml [UpdateManifests-img]: https://github.com/JuliaRegistries/General/actions/workflows/update_manifests.yml/badge.svg "Update Manifests status" 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 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: • MUST be mentioned in either the third party notice file or the license file (preferably the third party notice file). • SHOULD be mentioned in the README file. Please note that: • "README file" refers to the plain text file named , , or something similar. • "License file" refers to the plain text file named , , , or something similar. • "Third party notice file" refers to the plain text file named , , 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 or in the Pkg REPL mode to e.g. install the package , 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 or 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 fo…