# Build Julia on NixOS

**URL:** <https://discourse.julialang.org/t/build-julia-on-nixos/35129>\
**Category:** General Usage\
**Tags:** question, nixos\
**Created:** [February 25, 2020, 6:14pm UTC](https://discourse.julialang.org/t/build-julia-on-nixos/35129 "2020-02-25T18:14:16Z")\
**Posts on this page:** 15\
**Page:** 4

<div class="post-metadata">

**Author:** ![rikh](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/rikh/32/204104_2.png) [@rikh](https://discourse.julialang.org/u/rikh)\
**Post date:** [May 26, 2021, 9:38am UTC](https://discourse.julialang.org/t/build-julia-on-nixos/35129/63 "2021-05-26T09:38:23Z")

</div>

> [@jzr](#):
>
> Nix nirvana, you don’t want to go back to every little thing having its own package manager.

Although I’m a happy nix user indeed, I wouldn’t call depending on nix in CI jobs nirvana per se. Note that CI jobs are very important for most Julia developers. The whole CI ecosystem is built around stateful operating systems. I have used nix in CI and even [created a GitHub Action](https://github.com/rikhuijzer/cache-install) but can’t say that it has been a pleasant experience.

Like I said, unlike other languages, Julia has a solid package manager, so I don’t see the problem of using it.

> [@RCHG](#):
>
> There are several approaches to overcome this problem like `julia FHS` or during the compilation of Julia itself, but a julia2nix would be something nice as it could introduce the full tree of dependences of each package to ensure that everything is working smoothly in NixOS.

Good point.

---

<div class="post-metadata">

**Author:** ![jzr](https://avatars.discourse-cdn.com/v4/letter/j/eb9ed0/32.png) [@jzr](https://discourse.julialang.org/u/jzr)\
**Post date:** [May 26, 2021, 9:42am UTC](https://discourse.julialang.org/t/build-julia-on-nixos/35129/64 "2021-05-26T09:42:16Z")

</div>

The general product category of CI is mostly not great, so I can’t disagree on that point. Fwiw there are a bunch of CI services specifically built around being good for Nix. Drone, Hercules, etc.

Increasing Nix immersion is one of those cultural-technical experiences that can promote a certain way of thinking – that I happen to like, namely using [stateless systems](https://grahamc.com/blog/erase-your-darlings) everywhere.

---

<div class="post-metadata">

**Author:** ![mayl](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/mayl/32/25878_2.png) [@mayl](https://discourse.julialang.org/u/mayl)\
**Post date:** [June 7, 2021, 12:40pm UTC](https://discourse.julialang.org/t/build-julia-on-nixos/35129/65 "2021-06-07T12:40:29Z")

</div>

@ninjin is the new `julia_16-bin` expected to work with `nix-shell`? I’ve been trying it with `nix-shell -p julia_16-bin` although I can start the `julia` repl and get to the `pkg` prompt and install `Plots` and `GR` but when I run `using Plots; plot(rand(10))` I get:

```julia
env: ‘/home/larry/.julia/artifacts/716c009a184899dcd4e14fc566e3554d3e92f796/bin/gksqt’: No such file or directory

```

Followed by a bunch of messages like

```julia
GKS: GKS not in proper state. GKS must be either in the state WSOP or WSAC in routine ACTIVATE_WS

```

Is there a different way I should use this new package?

---

<div class="post-metadata">

**Author:** ![ninjin](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/ninjin/32/58_2.png) [@ninjin](https://discourse.julialang.org/u/ninjin)\
**Post date:** [June 7, 2021, 1:17pm UTC](https://discourse.julialang.org/t/build-julia-on-nixos/35129/66 "2021-06-07T13:17:38Z")

</div>

No, what you are experiencing is not due how you use the package but rather a standard NixOS issue: The `gksqt` binary needs to be patched with the correct interpreter. We should do this automatically by patching Pkg in the standard library, but I have not found the cycles to do this cleanly – although it should be fairly darn easy. But you can do it with a dirty hack for now:

```
chmod +w ~/.julia/artifacts/716c009a184899dcd4e14fc566e3554d3e92f796/bin/gksqt; nix-shell -p patchelf stdenv --command "patchelf --set-interpreter \"\$(cat \${NIX_CC}/nix-support/dynamic-linker)\" ~/.julia/artifacts/716c009a184899dcd4e14fc566e3554d3e92f796/bin/gksqt"

```

This messes up the artifact checksum, but it gets you up and working.

---

<div class="post-metadata">

**Author:** ![mayl](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/mayl/32/25878_2.png) [@mayl](https://discourse.julialang.org/u/mayl)\
**Post date:** [June 7, 2021, 1:39pm UTC](https://discourse.julialang.org/t/build-julia-on-nixos/35129/67 "2021-06-07T13:39:23Z")

</div>

Ah ok, that’s gotten me further I can now plot simple things. Trying to run the Lorenz attractor demo from the [Plots homepage](http://docs.juliaplots.org/latest/) hits a similar issue with `ffmpeg`, but now that I know what’s going on I was able to figure my way through it.

Thanks for the help and the work on `Julia` in `NixPkgs`, I’m looking forward to a more complete `Julia` system on `Nix`!

---

<div class="post-metadata">

**Author:** ![jzr](https://avatars.discourse-cdn.com/v4/letter/j/eb9ed0/32.png) [@jzr](https://discourse.julialang.org/u/jzr)\
**Post date:** [June 8, 2021, 1:04am UTC](https://discourse.julialang.org/t/build-julia-on-nixos/35129/68 "2021-06-08T01:04:21Z")

</div>

Does anybody have GLMakie working?

---

<div class="post-metadata">

**Author:** ![573](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/573/32/15770_2.png) [@573](https://discourse.julialang.org/u/573)\
**Post date:** [June 22, 2021, 9:22am UTC](https://discourse.julialang.org/t/build-julia-on-nixos/35129/69 "2021-06-22T09:22:54Z")

</div>

I still can’t get plots.

```sh
NIX_PATH=nixpkgs=http://nixos.org/channels/nixpkgs-unstable/nixexprs.tar.xz nix-shell -p julia_16-bin

```

```julia
pkg> add GRUtils
julia> ENV["GRDIR"] = ""
pkg> build GR
julia> using GRUtils
julia> x = LinRange(0, 10, 500)
julia> y = sin.(x.^2) .* exp.(-x)
julia> GR.plot(x, y)

```

yields this:

> ERROR: could not load library “libGR.so”  
> /nix/store/sbbifs2ykc05inws26203h0xwcadnf0l-glibc-2.32-46/lib/libc.so.6: version `GLIBC\_2.33’ not found (required by /home/dkahlenberg/.julia/packages/GR/4DHy8/src/…/deps/gr/lib/libGR.so)

---

<div class="post-metadata">

**Author:** ![573](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/573/32/15770_2.png) [@573](https://discourse.julialang.org/u/573)\
**Post date:** [June 22, 2021, 9:35am UTC](https://discourse.julialang.org/t/build-julia-on-nixos/35129/70 "2021-06-22T09:35:51Z")

</div>

To reply to myself [GR build problems: "installation is incomplete" - #26 by mkitti](https://discourse.julialang.org/t/gr-build-problems-installation-is-incomplete/58764/26) had the answer (somewhat hidden in the comment text) it was to use the explicit version providing `BinaryBuilder` as in:

```julia
pkg> add GR@0.57

```

---

<div class="post-metadata">

**Author:** ![logankilpatrick](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/logankilpatrick/32/38123_2.png) [@logankilpatrick](https://discourse.julialang.org/u/logankilpatrick)\
**Post date:** [June 22, 2021, 10:51am UTC](https://discourse.julialang.org/t/build-julia-on-nixos/35129/71 "2021-06-22T10:51:50Z")

</div>

Just popping in to say if you want to help add support for Julia on [https://Repl.it](https://Repl.it) with Nix, please feel free to chime in: [Bump Julia to 1.5.3 by logankilpatrick · Pull Request #222 · replit/polygott · GitHub](https://github.com/replit/polygott/pull/222)

---

<div class="post-metadata">

**Author:** ![RCHG](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/rchg/32/10104_2.png) [@RCHG](https://discourse.julialang.org/u/RCHG)\
**Post date:** [June 22, 2021, 3:57pm UTC](https://discourse.julialang.org/t/build-julia-on-nixos/35129/72 "2021-06-22T15:57:39Z")

</div>

Hello,

Here there is a nix code that is working for me with Julia 1.5 to produce plots. I think that a similar version has been shared before in this thread, but given that some users are asking for something that can produce plots, here it is one (for NixOS 20.09)

In my configuration.nix, it is included a call to a package where I define the julia 1.5 compilation with the needed libraries for plotting.

```julia

{ config, pkgs, lib, ... }:

let 
    myjulia = pkgs.callPackage ./julia_new15 {};

in 
{ ... }

```

the usual NixOS configuration can be inside the {…} but adding to `environment.systemPackages` the package above defined `myjulia`.

… and here is the file `julia_new15. nix`:

```julia
{ stdenv, fetchurl, fetchzip, fetchFromGitHub
# build tools
, gfortran, m4, makeWrapper, patchelf, perl, which, python2, python3, R, gmt
, cmake, netcdf, netcdffortran, hdf5-fortran
# libjulia dependencies
, libunwind, readline, utf8proc, zlib
# standard library dependencies
, curl, fftwSinglePrec, fftw, libgit2, mpfr, openlibm, openspecfun, pcre2
# linear algebra
, blas, lapack, arpack
}:

assert (!blas.isILP64) && (!lapack.isILP64);

with stdenv.lib;

let
  majorVersion = "1";
  minorVersion = "5";
  maintenanceVersion = "3";
  src_sha256 = "sha256:0jds8lrhk4hfdv7dg5p2ibzin9ivga7wrx7zwcmz6dqp3x792n1i";
  version = "${majorVersion}.${minorVersion}.${maintenanceVersion}";
in

stdenv.mkDerivation rec {
  pname = "julia";
  inherit version;

   src = fetchzip {
     url = "https://github.com/JuliaLang/julia/releases/download/v${version}/julia-${version}-full.tar.gz";
     sha256 = src_sha256;
   };

  patches = [
    ./use-system-utf8proc-julia-1.3.patch

    # Julia recompiles a precompiled file if the mtime stored *in* the
    # .ji file differs from the mtime of the .ji file. This
    # doesn't work in Nix because Nix changes the mtime of files in
    # the Nix store to 1. So patch Julia to accept mtimes of 1.
    
    ./allow_nix_mtime.patch
  ];

  postPatch = ''
     patchShebangs . contrib
    for i in backtrace cmdlineargs; do
      mv test/$i.jl{,.off}
      touch test/$i.jl
    done
    rm stdlib/Sockets/test/runtests.jl && touch stdlib/Sockets/test/runtests.jl
    rm stdlib/Distributed/test/runtests.jl && touch stdlib/Distributed/test/runtests.jl
    # LibGit2 fails with a weird error, so we skip it as well now
    rm stdlib/LibGit2/test/runtests.jl && touch stdlib/LibGit2/test/runtests.jl
    sed -e 's/Invalid Content-Type:/invalid Content-Type:/g' -i ./stdlib/LibGit2/test/libgit2.jl
    sed -e 's/Failed to resolve /failed to resolve /g' -i ./stdlib/LibGit2/test/libgit2.jl
  '';

  dontUseCmakeConfigure = true;

  buildInputs = [
    arpack fftw fftwSinglePrec libgit2 libunwind mpfr
    pcre2.dev blas lapack openlibm openspecfun readline utf8proc
    zlib python3 python2 R
  ];

  nativeBuildInputs = [curl gfortran m4 makeWrapper patchelf perl python2 python3 which cmake R gmt netcdf netcdffortran hdf5-fortran];

  makeFlags =
    let
      arch = head (splitString "-" stdenv.system);
      march = {
        x86_64 = stdenv.hostPlatform.platform.gcc.arch or "x86-64";
        i686 = "pentium4";
        aarch64 = "armv8-a";
      }.${arch}
              or (throw "unsupported architecture: ${arch}");
      # Julia requires Pentium 4 (SSE2) or better
      cpuTarget = { x86_64 = "x86-64"; i686 = "pentium4"; aarch64 = "generic"; }.${arch}
                  or (throw "unsupported architecture: ${arch}");
    # Julia applies a lot of patches to its dependencies, so for now do not use the system LLVM
    # https://github.com/JuliaLang/julia/tree/master/deps/patches
    in [
      "ARCH=${arch}"
      "MARCH=${march}"
      "JULIA_CPU_TARGET=${cpuTarget}"
      "PREFIX=$(out)"
      "prefix=$(out)"
      "SHELL=${stdenv.shell}"

      "USE_SYSTEM_BLAS=1"
      "USE_BLAS64=${if blas.isILP64 then "1" else "0"}"

      "USE_SYSTEM_LAPACK=1"

      "USE_SYSTEM_ARPACK=1"
      "USE_SYSTEM_FFTW=1"
      "USE_SYSTEM_GMP=0"
      "USE_SYSTEM_LIBGIT2=1"
      "USE_SYSTEM_LIBUNWIND=1"

      "USE_SYSTEM_MPFR=1"
      "USE_SYSTEM_OPENLIBM=1"
      "USE_SYSTEM_OPENSPECFUN=1"
      "USE_SYSTEM_PATCHELF=1"
      "USE_SYSTEM_PCRE=1"
      "PCRE_CONFIG=${pcre2.dev}/bin/pcre2-config"
      "PCRE_INCL_PATH=${pcre2.dev}/include/pcre2.h"
      "USE_SYSTEM_READLINE=1"
      "USE_SYSTEM_UTF8PROC=1"
      "USE_SYSTEM_ZLIB=1"

      "USE_BINARYBUILDER=0"
    ];

  LD_LIBRARY_PATH = makeLibraryPath [
    arpack fftw fftwSinglePrec libgit2 mpfr blas openlibm
    openspecfun pcre2 lapack python3 python3 R
  ];

  enableParallelBuilding = true;

  # Julia's tests require read/write access to $HOME
  preCheck = ''
    export HOME="$NIX_BUILD_TOP"
  '';

  preBuild = ''
    sed -e '/^install:/s@[^]*/doc/[^]*@@' -i Makefile
    sed -e '/[$](DESTDIR)[$](docdir)/d' -i Makefile
    export LD_LIBRARY_PATH=${LD_LIBRARY_PATH}
  '';

  postInstall = ''
    # Symlink shared libraries from LD_LIBRARY_PATH into lib/julia,
    # as using a wrapper with LD_LIBRARY_PATH causes segmentation
    # faults when program returns an error:
    # $ julia -e 'throw(Error())'
    find $(echo $LD_LIBRARY_PATH | sed 's|:| |g') -maxdepth 1 -name '*.${if stdenv.isDarwin then "dylib" else "so"}*' | while read lib; do
      if [[! -e $out/lib/julia/$(basename $lib)]]; then
        ln -sv $lib $out/lib/julia/$(basename $lib)
      fi
    done
  '';

  passthru = {
    inherit majorVersion minorVersion maintenanceVersion;
    site = "share/julia/site/v${majorVersion}.${minorVersion}";
  };

  meta = {
    description = "High-level performance-oriented dynamical language for technical computing";
    homepage = "https://julialang.org/";
    license = stdenv.lib.licenses.mit;
    maintainers = with stdenv.lib.maintainers; [raskin rob garrison];
    platforms = ["i686-linux" "x86_64-linux" "x86_64-darwin" "aarch64-linux"];
    broken = stdenv.isi686;
  };
}

```

---

<div class="post-metadata">

**Author:** ![mayl](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/mayl/32/25878_2.png) [@mayl](https://discourse.julialang.org/u/mayl)\
**Post date:** [July 4, 2021, 9:46am UTC](https://discourse.julialang.org/t/build-julia-on-nixos/35129/73 "2021-07-04T09:46:22Z")

</div>

Do you have any more thoughts on patching `Pkg` to make this work? I’ve been looking at it a tiny bit, but I’m pretty new to `Julia` so I’m not sure if I’m on the right track.

I saw where you suggested we might insert the call to `patchElf`, but do you think maybe [here](https://github.com/JuliaLang/Pkg.jl/blob/3e9bceeb2579173d48c52137bbd7b4c6578a8e4b/src/Artifacts.jl#L56) (i.e. after the hash has been calculated, but before the write bit is cleared) is a better option?

Do you have a sense for how “careful” we need to be with `patchElf`? Can we indiscriminately attempt to `patchElf` everything that comes in an artifact’s `bin` directory, or do we need to somehow test each one before patching in the `nix` dynamic linker?

I’m not familiar with the `Julia` `Pkg` system, are there cases we need to lookout for where stuff under `lib` also needs to be `patchElf`’d or are those standalone from `Pkg` already?

---

<div class="post-metadata">

**Author:** ![mayl](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/mayl/32/25878_2.png) [@mayl](https://discourse.julialang.org/u/mayl)\
**Post date:** [July 5, 2021, 9:14am UTC](https://discourse.julialang.org/t/build-julia-on-nixos/35129/74 "2021-07-05T09:14:00Z")

</div>

I did something… I’m not sure I’m _proud_ of it, but it’s at least a bit more convenient to get a new package installed. Here’s my `shell.nix`:

```julia
{pkgs ? import<nixpkgs>{} }:
with pkgs;

let
  fixJuliaPkgs = writeScriptBin "fixJuliaPkgs" ''
    #!/usr/bin/env bash

    PKG_DIR=~/.julia/

    for ARTIFACT in $(find $PKG_DIR/artifacts/*/bin) 
    do
      chmod +w $ARTIFACT
      ${patchelf}/bin/patchelf \
        $ARTIFACT \
        --set-interpreter \
        "$(cat $NIX_CC/nix-support/dynamic-linker)"
      chmod -w $ARTIFACT
    done
    '';
in
mkShell {
  buildInputs = [
    fixJuliaPkgs
    julia-stable-bin
  ];
}

```

Basically, it just introduces the `fixJuliaPkgs` script which attempts to `patchelf` everything in all the artifact `bin/` directories. I manually call it after adding a package with `Pkg`. So far, this _seems_ to work OK because `patchelf` is smart enough to only set the dynamic linker on files which are actually `elf` binaries, and which have a linker to set. It’s not elegant, but it’s a stop-gap for me until I find something better or `nixpkgs` patches `Pkg` to automatically `patchelf` on download.

I’ve also got this abomination on [GitHub](https://github.com/mayl/juliaShell). Feedback welcome!

---

<div class="post-metadata">

**Author:** ![laplace](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/laplace/32/27781_2.png) [@laplace](https://discourse.julialang.org/u/laplace)\
**Post date:** [August 3, 2021, 8:39am UTC](https://discourse.julialang.org/t/build-julia-on-nixos/35129/75 "2021-08-03T08:39:07Z")

</div>

hope someone fix it 😀

---

<div class="post-metadata">

**Author:** ![thomasjm](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/thomasjm/32/18984_2.png) [@thomasjm](https://discourse.julialang.org/u/thomasjm)\
**Post date:** [April 26, 2023, 4:03am UTC](https://discourse.julialang.org/t/build-julia-on-nixos/35129/76 "2023-04-26T04:03:27Z")

</div>

Hi all, I realize this is an old thread but I’ve been working on a more serious way to build Julia environments on NixOS. You can find it here:

> <https://github.com/NixOS/nixpkgs/pull/225513>
>
> \###### Description of changes
> 
> tl;dr: this PR offers a new approach to build a…rbitrary Julia environments in Nixpkgs, in the same style as \`python.withPackages\`. You can try it like this (using whatever packages you like):
> 
> \`\`\`bash
> gh pr checkout 225513 # Check out this branch
> nix run --impure --expr 'with import ./. {}; julia.withPackages \["Plots" "JSON3"\]'
> \`\`\`
> 
> \### How does it work?
> 
> The steps are documented in \`default.nix\`. To summarize:
> 
> 1. Establish a pinned version of the Julia \[General\](https://github.com/JuliaRegistries/General) registry. The version I've made is \[here\](https://github.com/CodeDownIO/General) and it's been specially preprocessed to add Nix sha256 hashes for every package version; more on this later.
> 2. Take our list of desired packages and invoke Julia's low-level package resolution function to get a full package closure, with UUIDs and version numbers for every desired package.
> 3. Generate a \`.nix\` file containing \`fetchgit\` calls for all the desired packages, leveraging sha256 hashes from the special registry.
> 4. Import the result of step 3 (IFD)
> 5. Construct a minimal Julia registry using the results of step 4. This minimal registry contains only the packages we need, and the \`repo\` fields have been replaced with on-disk paths in the Nix store.
> 6. Next, do a similar song and dance for Julia binary artifacts. Scan over all the downloaded packages and extract the artifacts they require, generating another \`.nix\` file.
> 7. Import the result of step 6 and use it to build an artifacts \`Overrides.toml\` pointing all the artifacts to local Nix store paths (IFD)
> 8. Assemble all of the above to create a Julia project folder and a Julia depot, then do a \`makeWrapper\` call on Julia to set everything up. You can optionally pass a boolean \`precompile\` to control whether everything gets precompiled.
> 9. Now you have a Nix-packaged Julia environment!
> 
> The only downside here is that this process involves IFD in step 4 and step 7. I'm hoping the benefits will outweigh the drawbacks here and the community will be willing to land this. In practical terms, the IFD means that Nix isn't able to process the package downloads and artifacts downloads in parallel, which means it takes a bit longer to run them sequentially. And possibly this isn't testable on Hydra. But still, Julia packaging has been a challenge for years and this gets it done!
> 
> If the IFD is a no-go, we could move the pieces around to make this a 2-step process where you first generate a set of \`.nix\` files, and then build them yourself, similar to \[julia2nix\](git@github.com:codedownio/julia2nix.git). IMO the ergonomics of that are worse though.
> 
> A couple other notes:
> 
> \* I put the full list of Julia package names in \`package-names.nix\`. The only purpose of this is to expose them in an \`attrset\`, so that it's easy to explore the available packages in a Nix repl. I figure it's not too big of a file, but we could remove it.
> 
> \###### Things done
> 
> 
> 
> \- Built on platform(s)
> - \[X\] x86\_64-linux
> - \[\] aarch64-linux
> - \[\] x86\_64-darwin
> - \[\] aarch64-darwin
> \- \[\] For non-Linux: Is \`sandbox = true\` set in \`nix.conf\`? (See \[Nix manual\](https://nixos.org/manual/nix/stable/command-ref/conf-file.html))
> \- \[\] Tested, as applicable:
> - \[NixOS test(s)\](https://nixos.org/manual/nixos/unstable/index.html#sec-nixos-tests) (look inside \[nixos/tests\](https://github.com/NixOS/nixpkgs/blob/master/nixos/tests))
> - and/or \[package tests\](https://nixos.org/manual/nixpkgs/unstable/#sec-package-tests)
> - or, for functions and "core" functionality, tests in \[lib/tests\](https://github.com/NixOS/nixpkgs/blob/master/lib/tests) or \[pkgs/test\](https://github.com/NixOS/nixpkgs/blob/master/pkgs/test)
> - made sure NixOS tests are \[linked\](https://nixos.org/manual/nixpkgs/unstable/#ssec-nixos-tests-linking) to the relevant packages
> \- \[\] Tested compilation of all packages that depend on this change using \`nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD"\`. Note: all changes have to be committed, also see \[nixpkgs-review usage\](https://github.com/Mic92/nixpkgs-review#usage)
> \- \[X\] Tested basic functionality of all binary files (usually in \`./result/bin/\`)
> \- \[23.05 Release Notes (or backporting 22.11 Release notes)\](https://github.com/NixOS/nixpkgs/blob/master/CONTRIBUTING.md#generating-2305-release-notes)
> - \[\] (Package updates) Added a release notes entry if the change is major or breaking
> - \[\] (Module updates) Added a release notes entry if the change is significant
> - \[\] (Module addition) Added a release notes entry if adding a new NixOS module
> \- \[X\] Fits \[CONTRIBUTING.md\](https://github.com/NixOS/nixpkgs/blob/master/CONTRIBUTING.md).

Feedback is welcome! If enough interested Julia users leave a thumbs up, maybe it will help overcome Nixpkgs maintainers’ dislike for import-from-derivation 🙂

---

<div class="post-metadata">

**Author:** ![idontgetoutmuch](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/idontgetoutmuch/32/321_2.png) [@idontgetoutmuch](https://discourse.julialang.org/u/idontgetoutmuch)\
**Post date:** [October 1, 2023, 1:00pm UTC](https://discourse.julialang.org/t/build-julia-on-nixos/35129/77 "2023-10-01T13:00:42Z")

</div>

This sounds great - I will be trying this out over the next month or so on darwin (macos M2)

[Previous page](https://discourse.julialang.org/t/build-julia-on-nixos/35129.md?page=3)