# Julia-forge, a conda channel for official Julia

**URL:** <https://discourse.julialang.org/t/julia-forge-a-conda-channel-for-official-julia/138511>\
**Category:** General Usage\
**Tags:** conda, pixi\
**Created:** [July 28, 2026, 1:08pm UTC](https://discourse.julialang.org/t/julia-forge-a-conda-channel-for-official-julia/138511 "2026-07-28T13:08:28Z")\
**Posts on this page:** 2\
**Page:** 1

<div class="post-metadata">

**Author:** ![mkitti](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/mkitti/32/12459_2.png) [@mkitti](https://discourse.julialang.org/u/mkitti)\
**Post date:** [July 28, 2026, 1:08pm UTC](https://discourse.julialang.org/t/julia-forge-a-conda-channel-for-official-julia/138511/1 "2026-07-28T13:08:28Z")

</div>

A couple of years ago Wolf Vollprecht created a conda channel called julia-forge that repackges official Julia downloads as conda packages:

> **[prefix.dev – solving software package management](https://prefix.dev/channels/julia-forge)**
>
> The software package management platform for Python, C++, R, Rust and more

Recently, I revived the project by adding recent stable (1.12.6) and long term support (LTS) builds (1.10.11). I also added an additional LTS channel which does not contain the latest stable builds.

> **[prefix.dev – solving software package management](https://prefix.dev/channels/julia-forge-lts)**
>
> The software package management platform for Python, C++, R, Rust and more

The revival mimics logic based on juliaup to monitor version releases. The two channels are meant to mimic juliaup’s release and lts channels.

This differs from the conda-forge builds which are built from source by conda-forge. While noble in premise, it has been difficult to properly coordinate the dependencies in the conda-forge ecosystem leading to some unresolved issues such as the lack of Windows support.

While at the moment, this is mainly meant to provide a mechanism to provide official Julia binaries via conda, mamba, and pixi, I am also considering providing julia packages _with their precompile caches_ targeted towards a generic microarchitectures. My main focus with this would be to make it easier to install packages with long precompilation times such as the Makie ecosystem or introductory packages such as Pluto.jl.

Lastly, thank you to @visr for also adding Linux aadch64 packages:

> <https://github.com/wolfv/julia-forge/pull/7>
>
> \## What changed
> 
> \- add \`linux-aarch64\` to the shared build matrix
> \- run it na…tively on GitHub's \`ubuntu-24.04-arm\` runner, without emulation
> 
> \## Why
> 
> Both \`julia/recipe.yaml\` and \`julia-lts/recipe.yaml\` already define Linux AArch64 sources and checksums, but CI omitted that target. As a result, the \`julia-forge\` channels do not publish Linux AArch64 packages and downstream users cannot resolve Julia 1.12.6 on that platform.
> 
> Because release and LTS builds share this matrix, the new job builds and tests both recipes. The existing trusted-publishing steps then upload the release package to \`julia-forge\` and the LTS package to both \`julia-forge-lts\` and \`julia-forge\` on pushes or manual runs.
> 
> \## Validation
> 
> Rendered and solved both recipes locally with \`--target-platform linux-aarch64\`:
> 
> \- release: Julia 1.12.6, selecting the existing Linux AArch64 URL and checksum
> \- LTS: Julia 1.10.11, selecting the existing Linux AArch64 URL and checksum
> 
> The PR workflow will perform the full builds and Julia smoke tests natively on ARM64.
> 
> \## Background
> 
> I ran into this switching from \`conda-forge/juliaup\` to \`julia-forge/julia\` in https://github.com/Deltares/Ribasim/pull/3176. I used AI (GPT-5.6) to make this PR, but reviewed it myself.

Contributions are welcome!

## Pixi instructions:

```julia-auto
pixi workspace channel add --prepend https://prefix.dev/julia-forge
pixi add julia

```

Or

```julia-auto
pixi add https://prefix.dev/julia-forge::julia

```

You can also configure pixi.toml as follows.

```julia-auto
[workspace]
name = "my-workspace"
channels = ["https://prefix.dev/julia-forge", "conda-forge"]
platforms = ["linux-64", "osx-arm64", "osx-64", "win-64"]

[dependencies]
julia = "*"

```

## Mamba instructions

```julia-auto
mamba install -c https://prefix.dev/julia-forge julia

```

## Conda instructions

```julia-auto
conda install -c https://prefix.dev/julia-forge julia

```

edit: I originally stated the channel URL incorrect with an extra `channels/` directory. Also pixi does not have a `--channel` flag.

---

<div class="post-metadata">

**Author:** ![mattsignorelli](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/mattsignorelli/32/221502_2.png) [@mattsignorelli](https://discourse.julialang.org/u/mattsignorelli)\
**Post date:** [August 2, 2026, 8:53pm UTC](https://discourse.julialang.org/t/julia-forge-a-conda-channel-for-official-julia/138511/2 "2026-08-02T20:53:02Z")

</div>

Related:

> [@Pre-built binaries via the registry](https://discourse.julialang.org/t/pre-built-binaries-via-the-registry/134515):
>
> Right now precompilation is run on users’ computers after they add a package. Sometimes these can take a very long time (e.g. Makie.jl or DifferentialEquations.jl). Sure, you only have to do it once, but then you have to do it again every time there is an update. And whether you like it or not, it will make new users immediately think “Wow, it takes seconds to conda install something, Julia is comparatively so slow”. Also thinking about [this recent post](https://www.reddit.com/r/Julia/comments/1pka4gw/so_wth_is_wrong_with_julia/). In my view, such frustrations are comple…

I’ve found that currently having to wait centuries to precompile when installing/updating/adding packages is a major pain point for me and many new users I work with, as they always compare to the instant downloads achieved with Python packages. I would love a solution to this problem