Are extension packages importable?

mkitti · January 4, 2023, 10:27pm

~~My vague understanding is that extension packages are true packages on their own. You could probably add them as subdirectory packages.~~

I think @kristoffer.carlsson would be the one most qualified to clarify this.

Here is the pull request to Julia:

github.com/JuliaLang/julia

Add support for "package extensions" to code loading

JuliaLang:master ← JuliaLang:kc/glue

opened 04:03PM - 24 Nov 22 UTC

KristofferC

+406 -24

This is an implementation of the proposal in https://github.com/JuliaLang/julia/…issues/43119 (with some tweaks) that aims to replace Requires.jl for loading code based on the presence of other packages. It is a different implementation to https://github.com/JuliaLang/julia/pull/47040 and should work better in for example big environments where you expect to only load a small subset of packages. In spirit, it is very similar to Requires.jl in that given a set of packages and a file, you load the file when those packages have been loaded in the julia session. The differences to Requires.jl are: - The file with the conditional code gets precompiled in the same way as a normal package would. Requires.jl instead directly evaluates the code into the package. - It is possible to use Pkg to set compatibility on the packages that "activates" the conditional code. This is a new feature in Pkg and could in theory also be used together with Requires.jl. - It is "declarative" in the sense that all information requires id stored in the Project.toml and Manifest.toml file so it avoids having to run any arbitrary Julia code in e.g. `__init__` (which is done when using Requries.jl). The added docs in code loading as well as the added docs in the accompanying Pkg PR (https://github.com/JuliaLang/Pkg.jl/pull/3264) can be used to get a more detail description of its usage. A lot of the diff in this PR is due to the code loading being pretty awkward and would have been easier to be built on top of https://github.com/JuliaLang/julia/pull/46690 but I don't want to couple those PRs. For reviewers: going through all the uuid lookups etc in the code loading is probably fairly uninteresting since it is mostly mechanical, the interesting parts are those around line 1080 - 1200 in `loading.jl` which deals with the insertion of gluepkgs "callbacks" and the loading of them. An example of a real package moving from Requires.jl to using this system can be seen in https://github.com/KristofferC/PGFPlotsX.jl/compare/kc/glue. It should be pretty easy to be backwards compatible with Requires. You just put the `@require` inside a version check and include the file for the conditional file in the `@require` block. One TODO that is left is that Pkg should precompile these "glue packages" during `Pkg.precompile` (which is often run automatically) in the case of them having a chance to be loaded in the current environment.

and the corresponding pull request to Pkg.jl:

Here are some example extension modules:

It appears that these modules do not have UUIDs so they may not be bonafide packages in themselves. The example prototypes show the extensions are usually modules which are included as submodules of the base package.