nixpkgs/pkgs/development/compilers/julia
Silvan Mosberger 4f0dadbf38 treewide: format all inactive Nix files
After final improvements to the official formatter implementation,
this commit now performs the first treewide reformat of Nix files using it.
This is part of the implementation of RFC 166.

Only "inactive" files are reformatted, meaning only files that
aren't being touched by any PR with activity in the past 2 months.
This is to avoid conflicts for PRs that might soon be merged.
Later we can do a full treewide reformat to get the rest,
which should not cause as many conflicts.

A CI check has already been running for some time to ensure that new and
already-formatted files are formatted, so the files being reformatted here
should also stay formatted.

This commit was automatically created and can be verified using

    nix-build a08b3a4d19.tar.gz \
      --argstr baseRev b32a094368
    result/bin/apply-formatting $NIXPKGS_PATH
2024-12-10 20:26:33 +01:00
..
patches julia_16-bin: drop 2024-10-11 16:09:12 -04:00
default.nix julia_111: 1.11.1 -> 1.11.2 2024-12-04 20:28:42 -05:00
generic-bin.nix treewide: format all inactive Nix files 2024-12-10 20:26:33 +01:00
generic.nix
README.md

Julia

Julia, as a full-fledged programming language with an extensive standard library that covers numerical computing, can be somewhat challenging to package. This file aims to provide pointers which could not easily be included as comments in the expressions themselves.

For Nixpkgs, the manual is as always your primary reference, and for the Julia side of things you probably want to familiarise yourself with the README , build instructions, and release process. Remember that these can change between Julia releases, especially if the LTS and release branches have deviated greatly. A lot of the build process is underdocumented and thus there is no substitute for digging into the code that controls the build process. You are very likely to need to use the test suite to locate and address issues and in the end passing it, while only disabling a minimal set of broken or incompatible tests you think you have a good reason to disable, is your best bet at arriving at a solid derivation.