# Call to write 1.9 extensions (and find pkgs that need those)

**URL:** <https://discourse.julialang.org/t/call-to-write-1-9-extensions-and-find-pkgs-that-need-those/98857>\
**Category:** Community\
**Tags:** package-extensions\
**Created:** [May 15, 2023, 2:38am UTC](https://discourse.julialang.org/t/call-to-write-1-9-extensions-and-find-pkgs-that-need-those/98857 "2023-05-15T02:38:48Z")\
**Posts on this page:** 20\
**Page:** 1

<div class="post-metadata">

**Author:** ![longemen3000](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/longemen3000/32/7298_2.png) [@longemen3000](https://discourse.julialang.org/u/longemen3000)\
**Post date:** [May 15, 2023, 2:38am UTC](https://discourse.julialang.org/t/call-to-write-1-9-extensions-and-find-pkgs-that-need-those/98857/1 "2023-05-15T02:38:48Z")

</div>

1.9 Extensions are great, we need more of those. They are a great step into the dream of infinite interoperability that is one of my main motivators to use julia. For those reasons, i hereby make a call to extend as much packages as possible.

A first concrete step in that direction is a place to collect packages that could benefit of the use of extensions (if there is a GH issue, great!, make that issue visible here). This post is a good place as any to do that.

---

<div class="post-metadata">

**Author:** ![gdalle](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/gdalle/32/27854_2.png) [@gdalle](https://discourse.julialang.org/u/gdalle)\
**Post date:** [May 15, 2023, 6:05am UTC](https://discourse.julialang.org/t/call-to-write-1-9-extensions-and-find-pkgs-that-need-those/98857/2 "2023-05-15T06:05:14Z")

</div>

Putting this here as an easy way to ensure backwards compatibility with Requires: [GitHub - cjdoris/PackageExtensionTools.jl: Makes Julia's package extensions backwards compatible](https://github.com/cjdoris/PackageExtensionTools.jl)

---

<div class="post-metadata">

**Author:** ![aplavin](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/aplavin/32/222056_2.png) [@aplavin](https://discourse.julialang.org/u/aplavin)\
**Post date:** [May 15, 2023, 11:56am UTC](https://discourse.julialang.org/t/call-to-write-1-9-extensions-and-find-pkgs-that-need-those/98857/3 "2023-05-15T11:56:31Z")

</div>

A related question: I wonder if it’s worth to turn very small and lightweight dependencies into extensions. Will it cause more overhead than any potential savings?  
I’m talking about small packages like `InverseFunctions` or `ConstructionBase`.

---

<div class="post-metadata">

**Author:** ![Oscar\_Smith](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/oscar_smith/32/25343_2.png) [@Oscar\_Smith](https://discourse.julialang.org/u/Oscar_Smith)\
**Post date:** [May 15, 2023, 2:08pm UTC](https://discourse.julialang.org/t/call-to-write-1-9-extensions-and-find-pkgs-that-need-those/98857/4 "2023-05-15T14:08:07Z")

</div>

No. Lightweight packages are fine. The place where you need extensions are where you want a small amount of code to make another large package work well.

---

<div class="post-metadata">

**Author:** ![aplavin](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/aplavin/32/222056_2.png) [@aplavin](https://discourse.julialang.org/u/aplavin)\
**Post date:** [May 15, 2023, 2:31pm UTC](https://discourse.julialang.org/t/call-to-write-1-9-extensions-and-find-pkgs-that-need-those/98857/5 "2023-05-15T14:31:10Z")

</div>

However, more and more packages turn very lightweight dependencies into extensions: [1](https://github.com/search?q=InverseFunctions+repo%3AJuliaRegistries%2FGeneral+path%3A**%2FWeakDeps.toml&type=code&ref=advsearch) [2](https://github.com/search?q=ChainRulesCore+repo%3AJuliaRegistries%2FGeneral+path%3A**%2FWeakDeps.toml&type=code&ref=advsearch) etc. Should this be “officially” discouraged?

---

<div class="post-metadata">

**Author:** ![Oscar\_Smith](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/oscar_smith/32/25343_2.png) [@Oscar\_Smith](https://discourse.julialang.org/u/Oscar_Smith)\
**Post date:** [May 15, 2023, 2:35pm UTC](https://discourse.julialang.org/t/call-to-write-1-9-extensions-and-find-pkgs-that-need-those/98857/6 "2023-05-15T14:35:02Z")

</div>

The `ChainRulesCore` (and similar packages like `StaticArraysCore`) are somewhat of an exception to this as they are packages that were made specifically to work around the fact that weakdeps didn’t exist. With a little luck, over the next couple years, all of those \*Core packages will go away and we will just be using weakdeps on the full versions.

---

<div class="post-metadata">

**Author:** ![aplavin](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/aplavin/32/222056_2.png) [@aplavin](https://discourse.julialang.org/u/aplavin)\
**Post date:** [May 15, 2023, 2:39pm UTC](https://discourse.julialang.org/t/call-to-write-1-9-extensions-and-find-pkgs-that-need-those/98857/7 "2023-05-15T14:39:31Z")

</div>

Ok, that was only one of my examples. What about InverseFunctions and similar, like ChangesOfVariables?  
And even [stdlibs](https://github.com/search?q=Random+OR+LinearAlgebra+OR+Dates+repo%3AJuliaRegistries%2FGeneral+path%3A**%2FWeakDeps.toml&type=code&ref=advsearch) sometimes get added as weakdeps.

---

<div class="post-metadata">

**Author:** ![cjdoris](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/cjdoris/32/213133_2.png) [@cjdoris](https://discourse.julialang.org/u/cjdoris)\
**Post date:** [May 15, 2023, 5:54pm UTC](https://discourse.julialang.org/t/call-to-write-1-9-extensions-and-find-pkgs-that-need-those/98857/8 "2023-05-15T17:54:17Z")

</div>

> [@gdalle](#):
>
> Putting this here as an easy way to ensure backwards compatibility with Requires: [GitHub - cjdoris/PackageExtensionTools.jl: Makes Julia’s package extensions backwards compatible](https://github.com/cjdoris/PackageExtensionTools.jl)

Guess I should tidy and release it.

---

<div class="post-metadata">

**Author:** ![longemen3000](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/longemen3000/32/7298_2.png) [@longemen3000](https://discourse.julialang.org/u/longemen3000)\
**Post date:** [May 15, 2023, 7:39pm UTC](https://discourse.julialang.org/t/call-to-write-1-9-extensions-and-find-pkgs-that-need-those/98857/9 "2023-05-15T19:39:42Z")

</div>

some package suggestions (just from my personal point of view):

- Roots + Measurements (avoid iterating naively)
- Makie extensions to packages that already have plot recipes
- ImplicitDifferenciation.jl to all the things that can support it

---

<div class="post-metadata">

**Author:** ![Zach\_Christensen](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/zach_christensen/32/7220_2.png) [@Zach\_Christensen](https://discourse.julialang.org/u/Zach_Christensen)\
**Post date:** [May 15, 2023, 8:20pm UTC](https://discourse.julialang.org/t/call-to-write-1-9-extensions-and-find-pkgs-that-need-those/98857/10 "2023-05-15T20:20:54Z")

</div>

This may actually be a good time to start putting together (whether for style guides or elsewhere) a list of recommended extensions packages based on what is being developed.

---

<div class="post-metadata">

**Author:** ![juliohm](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/juliohm/32/215266_2.png) [@juliohm](https://discourse.julialang.org/u/juliohm)\
**Post date:** [May 15, 2023, 10:45pm UTC](https://discourse.julialang.org/t/call-to-write-1-9-extensions-and-find-pkgs-that-need-those/98857/11 "2023-05-15T22:45:10Z")

</div>

I didn’t have the time to read the package extensions functionality yet, but if anyone wants to help, we have a very concrete use case in our stack. We would like to move the Makie.jl recipes developed in MeshViz.jl to Meshes.jl so that whenever a Makie.jl backend is loaded in the same session, the recipes are loaded as well.

My main concern with package extensions so far is that the LTS version doesn’t support it. I understand that we need to drop support of LTS to move forward with the new language feature.

---

<div class="post-metadata">

**Author:** ![Zach\_Christensen](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/zach_christensen/32/7220_2.png) [@Zach\_Christensen](https://discourse.julialang.org/u/Zach_Christensen)\
**Post date:** [May 16, 2023, 1:04am UTC](https://discourse.julialang.org/t/call-to-write-1-9-extensions-and-find-pkgs-that-need-those/98857/12 "2023-05-16T01:04:41Z")

</div>

Is there a clear path forward with what’s going on between GeometryBasics.jl and Meshes.jl? As someone not involved in that development I find it confusing what I’m supposed to be doing with those packages.

---

<div class="post-metadata">

**Author:** ![juliohm](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/juliohm/32/215266_2.png) [@juliohm](https://discourse.julialang.org/u/juliohm)\
**Post date:** [May 16, 2023, 1:28am UTC](https://discourse.julialang.org/t/call-to-write-1-9-extensions-and-find-pkgs-that-need-those/98857/13 "2023-05-16T01:28:09Z")

</div>

This question is off-topic. We can discuss in private if you need further clarification. Bellow is a short answer:

These two packages are used in completely separate software stacks with different goals.

If you need advanced geometric processing besides visualization with Makie.jl then I strongly recommend using Meshes.jl.

MeshViz.jl provides the recipes to plot Meshes.jl geometries with tons of customization. These recipes call Makie.jl built-in functions, which in turn are implemented in terms of their internal GeometryBasics.jl types.

Similarly, MeshPlots.jl provides recipes which are implemented in terms of Plots.il built-in functions and geometries defined in the backends (e.g. GR).

It is really a matter of asking yourself what you want to do with these geometries. If you want to manipulate them in Julia and do further work before visualization, Meshes.jl is the most adequate choice.

---

<div class="post-metadata">

**Author:** ![Zach\_Christensen](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/zach_christensen/32/7220_2.png) [@Zach\_Christensen](https://discourse.julialang.org/u/Zach_Christensen)\
**Post date:** [May 16, 2023, 1:59am UTC](https://discourse.julialang.org/t/call-to-write-1-9-extensions-and-find-pkgs-that-need-those/98857/14 "2023-05-16T01:59:16Z")

</div>

Gotcha. This distinction is pretty critical for other developers and fits within my previous comment pretty well. There needs to be text somewhere clearly stating this sort of stuff for the many packages that should have some form of plot support through an extension.

---

<div class="post-metadata">

**Author:** ![jlapeyre](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/jlapeyre/32/4514_2.png) [@jlapeyre](https://discourse.julialang.org/u/jlapeyre)\
**Post date:** [May 16, 2023, 2:43pm UTC](https://discourse.julialang.org/t/call-to-write-1-9-extensions-and-find-pkgs-that-need-those/98857/16 "2023-05-16T14:43:48Z")

</div>

Understanding all of the pros and cons, and also the steps one needs to take to convert a package would be useful.

- It would be useful to include the docstrings for functions in the extension in docs generated by Documenter.jl. I dont know how to do this. You can attach documentation to the declaration in the main package. Is this a perfect substitute? What about docs for calls with particular arguments?

- What about linting and testing the extension pacakges, `Test`, `Aqua`, `JET` ?

- If I understand correctly, you can’t cache native code for work that includes extensions. Is there a workaround? If not, you should be careful about prematurely converting a dep to a weak dep.

---

<div class="post-metadata">

**Author:** ![StefanKarpinski](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/stefankarpinski/32/24_2.png) [@StefanKarpinski](https://discourse.julialang.org/u/StefanKarpinski)\
**Post date:** [May 16, 2023, 2:53pm UTC](https://discourse.julialang.org/t/call-to-write-1-9-extensions-and-find-pkgs-that-need-those/98857/17 "2023-05-16T14:53:45Z")

</div>

The first obvious approach is to look for packages that currently use Requires and replace that with extensions instead.

---

<div class="post-metadata">

**Author:** ![juliohm](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/juliohm/32/215266_2.png) [@juliohm](https://discourse.julialang.org/u/juliohm)\
**Post date:** [May 16, 2023, 3:01pm UTC](https://discourse.julialang.org/t/call-to-write-1-9-extensions-and-find-pkgs-that-need-those/98857/18 "2023-05-16T15:01:54Z")

</div>

A first example could be

> **[GitHub - JuliaML/DensityRatioEstimation.jl: Density ratio estimation in Julia](https://github.com/JuliaML/DensityRatioEstimation.jl)**
>
> Density ratio estimation in Julia. Contribute to JuliaML/DensityRatioEstimation.jl development by creating an account on GitHub.

It uses Requires.jl to load optimization solvers with JuMP.jl, Convex.jl and Optim.jl.

---

<div class="post-metadata">

**Author:** ![mbauman](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/mbauman/32/31082_2.png) [@mbauman](https://discourse.julialang.org/u/mbauman)\
**Post date:** [May 16, 2023, 3:13pm UTC](https://discourse.julialang.org/t/call-to-write-1-9-extensions-and-find-pkgs-that-need-those/98857/19 "2023-05-16T15:13:58Z")

</div>

Are there any cons? I don’t think there are any over using Requires beyond the time and effort to do the conversion (but, yes, I suppose the situation may be different if you’re converting a direct dependency to a weak one). Here’s a previous thread with a run-down on you you convert Requires to an Extension in a backwards compatible manner:

> [@Package extensions for Julia \< 1.9](https://discourse.julialang.org/t/package-extensions-for-julia-1-9/93397):
>
> Package extensions are an exciting new feature of julia 1.9 
> 
> > **{links for more info about them}**
> >
> > \<a href="https://github.com/JuliaLang/julia/blob/v1.9.0-beta3/NEWS.md#package-manager" class="inline-onebox" rel="noopener nofollow ugc"\>julia/NEWS.md at v1.9.0-beta3 · JuliaLang/julia · GitHub\</a\> \<a href="https://pkgdocs.julialang.org/dev/creating-packages/#Conditional-loading-of-code-in-packages-(Extensions)"\>https://pkgdocs.julialang.org/dev/c…

And as for that list, here are [Requires’ dependencies](https://juliahub.com/ui/Packages/Requires/IyxeS/1.3.0?page=2) (although this will also catch those that only use Requires for backwards compatibility):

> Direct Dependents (566)

---

<div class="post-metadata">

**Author:** ![kellertuer](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/kellertuer/32/220707_2.png) [@kellertuer](https://discourse.julialang.org/u/kellertuer)\
**Post date:** [May 16, 2023, 4:37pm UTC](https://discourse.julialang.org/t/call-to-write-1-9-extensions-and-find-pkgs-that-need-those/98857/20 "2023-05-16T16:37:14Z")

</div>

One con that I did notice is that with Requires one can actually define structs in the added code (now: extension) to the original package.  
Sure that is not so reasonable, but took me a while to find a good alternative way to accomplish the same without introducing a new struct (that the parent package should even export).

But ± finishing that PR, one (more) of the 566 dependencies of Requires is soon based on extensions.

---

<div class="post-metadata">

**Author:** ![nilshg](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/nilshg/32/2283_2.png) [@nilshg](https://discourse.julialang.org/u/nilshg)\
**Post date:** [May 16, 2023, 4:38pm UTC](https://discourse.julialang.org/t/call-to-write-1-9-extensions-and-find-pkgs-that-need-those/98857/21 "2023-05-16T16:38:06Z")

</div>

There’s a recent issue with Plots and IJulia where the extension doesn’t really work:

> <https://github.com/JuliaPlots/Plots.jl/issues/4719>
>
> \## Details
> 
> IJulia is a bit peculiar in that you can really only have one vers…ion of it at the same time, otherwise one get's these "IJulia version doesn't match ..." warnings. This is because the (default) Jupyter kernelspec is bound to a specific IJulia version (since "kernel.json" points to \`".julia/packages/IJulia/SOME\_VERSION/src/kernel.jl"\`). So one (at least me) typically keeps IJulia in the default (e.g. "v1.9") environment and out of specific project environment like the the "Project/Manifest.toml" kept next to a notebook.
> 
> This leads to the following problem with the current Plots version on Julia v1.9, though:
> 
> \`\`\`
> using Plots
> 
> \[Info: Precompiling IJuliaExt \[2f4121a4-3b3a-5ce6-9c5e-1f2673ce168a\]
> ERROR: LoadError: ArgumentError: Package IJulia \[7073ff75-c697-5162-941a-fcdaad2a7d2a\] is required but does not seem to be installed:
> - Run \`Pkg.instantiate()\` to install all recorded dependencies.
> \`\`\`
> 
> This is very inconvenient, the only solution seems to be having IJulia in the notebook environment, but this would require having a separate Jupyter kernel for each notebook environment as well (or at lease having quite a few kernels). It's also really confusion to (esp. newer) users, because they can run \`using IJulia\` in the same notebook before \`using Plots\` cell without error, so IJulia is "there" (just not in an extension-compatible way).
> 
> IJulia is special here because it's automatically loaded without being part of the notebook, and because the "kernel.json" issue, Plot's other Pkg-extensions don't have to be this problem.
> 
> I would suggest the we handle IJulia via Requires again. Most (all) \`...\_ijulia\_...\` function in "IJuliaExt.jl" could be defined in Plots itself, since they don't depend on IJulia, so Requires would only need to load a few lines IJulia-specific code.
> 
> \### Backends
> 
> Not backend-specific.
> 
> \### Versions
> 
> Plots.jl version: v1.38.9
> Backend version (\`\]st -m \<backend(s)\>\`): Not backend-specific
> Output of \`versioninfo()\`:
> 
> \`\`\`
> Julia Version 1.9.0-rc2
> Commit 72aec423c2a (2023-04-01 10:41 UTC)
> Platform Info:
> OS: Linux (x86\_64-linux-gnu)
> CPU: 16 × Intel(R) Core(TM) i9-9880H CPU @ 2.30GHz
> WORD\_SIZE: 64
> LIBM: libopenlibm
> LLVM: libLLVM-14.0.6 (ORCJIT, skylake)
> \`\`\`

[Next page](https://discourse.julialang.org/t/call-to-write-1-9-extensions-and-find-pkgs-that-need-those/98857.md?page=2)