jiebi/CodeConvo huggingface dataset:
Code change:
inherit (darwin.apple_sdk.frameworks) CoreServices ApplicationServices; }; <del> julia_15 = callPackage ../development/compilers/julia/1.5.nix { </del> <ins> julia_15 = callPackage ../development/compilers/julia/1.5.nix { </ins> inherit (darwin.apple_sdk.frameworks) CoreServices ApplicationServices; }; julia_1 = julia_10; <del> julia = julia_1; </del> <ins> julia = julia_15; </ins> jwasm =  callPackage ../development/compilers/jwasm { };

Related discussion:
text: Am I wrong?
I just tried it with Julia 1.4 installed with Nix, and as I suspected fails to build due to
We need to have a interface - that would support building binary packages, and make the interpreter aware of them. I wish I was a bit more motivated to do this, but upstream disappoints me regarding the humble task of compiling Julia as is, with the right selection of a few system dependencies - no response at all at & . I'm also dis-motivated to explore this aspect, since their build system is of plain makefiles, and they keep patches of dependencies from so long ago, without documenting whether they are needed / used or not...
Nix behind It is a shame to see julia's support in NixOS languish. It seems pretty clear to me that upstream is only interested in supporting the configuration obtained by cloning their repository and typing on a stock Linux distribution. I understand their perspective in many ways, as having julia and all of its packages "just work" requires a lot of care, and building with unsupported configurations is very likely to result in brokenness somewhere in the package ecosystem if not in julia itself. Julia is a bit special in this regard because of its emphasis on performance and also its need to support interfaces to other languages/frameworks that often have weird requirements. I have found that typically, there is very good reason for these patches, even though at times they may not be documented except in git and github history. (Admittedly, I am less involved in upstream than I used to be.)
I think Julia team initially evaluated Nix as their binary distributor () but decided against it—there was a discussion somewhere but can’t find it. IIRC lack of Windows / desire to tie into native pkg management systems were factors. Julia’s does a pretty great job, and uses a solver to properly resolve dependency versions based on constraints. I’ve been incredibly frustrated by the withPackages pattern, at least in python. I constantly run into problems due to nixpkgs ignoring version constraints. There are some other nice advantages to nix of course: binary dependencies are shared across language ecosystems for example, and there are lots of supremely annoying packages (I’m looking at you CUDA...) that Nix makes delightfully easy to install, use, and maintain parallel versions.
Code change:
inherit (darwin.apple_sdk.frameworks) CoreServices ApplicationServices; }; <del> julia_15 = callPackage ../development/compilers/julia/1.5.nix { </del> <ins> julia_15 = callPackage ../development/compilers/julia/1.5.nix { </ins> inherit (darwin.apple_sdk.frameworks) CoreServices ApplicationServices; }; julia_1 = julia_10; <del> julia = julia_1; </del> <ins> julia = julia_15; </ins> jwasm =  callPackage ../development/compilers/jwasm { };

Related discussion:
text: But until Nixpkgs supports multiple versions across the board, and has a solver baked in, I’m honestly not sure Nix brings enough advantages to bail on Edit: I think the approach done by poetry2nix and Mach-nix are the way to go for Julia packages + nix. yarn2nix is another shining example. I would love to see a solution in this vein—didn’t mean to douse any enthusiasm for people interested in helping improve the Julia situation on NixOS :)
Maybe it is worth to reaching out to Julia Computing folks at to get their attention on ?
We'd probably need to put this information in our attribute sets, just like our Python packages know what deps they need. Hmm that's a bit surprising to hear as the Python ecosystem seems most well organized. Have you ever encountered a real bug with a mismatched version of a dependency with a specific version specified in a package's ? IIRC fails if a version is used and it's not exactly what's available. If you've ever felt there's a certain python package of a certain version missing, have you considered contributing it? Even if not, was it too hard to override it? What do you mean "across the board"? That might be much more harder then it sounds, due to the constraints of Nix it self when being evaluated everytime you run and friends, see It's not a question of whether Nix brings an advantage or not, it's a question of whether there are any Julia packages that are built at other distros imperatively with a , and this produces (or even worse, downloads) shared objects or executables into (not in ), linked to Julia or other Nix deps that do reside in . If the answer is yes, than every Nix user will experience breakage after Julia is updated in his - not necessarily if it's a version bump of Julia, it could be a mere rebuild of Julia by hydra. Yea Mach-nix is an awesome idea well implemented ( thanks for the inspiration :heart:). I've also reached a similar conclusion at . However, this is my opinion for Rust and Go, and I tend to think that for a small ecosystem like Julia, perhaps it'll be too much - it shouldn't be that hard to manage all of these pacakges like Python is managed in Nixpkgs.
I opened
Frequently.
Code change:
inherit (darwin.apple_sdk.frameworks) CoreServices ApplicationServices; }; <del> julia_15 = callPackage ../development/compilers/julia/1.5.nix { </del> <ins> julia_15 = callPackage ../development/compilers/julia/1.5.nix { </ins> inherit (darwin.apple_sdk.frameworks) CoreServices ApplicationServices; }; julia_1 = julia_10; <del> julia = julia_1; </del> <ins> julia = julia_15; </ins> jwasm =  callPackage ../development/compilers/jwasm { };

Related discussion:
text: Especially with Scipy, matplotlib, bokeh, sklearn, tensorflow, pytorch, etc... Often, nixpkgs used to have it until it was updated. Except in very rare circumstances, we do not keep more than one version of a python package around. I have no interest wasting time working around bugs that authors tried to spare me by specifying precise versions. It seems a sort of cognitive dissonance in our next community that we all care so deeply about reproducible builds, but for convenience often disregard the officially supported dependencies. As a result, there are often subtle bugs in software on NixOS that do not appear on other platforms. (Eg x11vnc crashes, shared memory problems, etc). Nix supports crazy high specificity in versioning, well we past semantic versioning down the the bit in many cases. And yet in nixpkgs, by convention, we remove the old version anytime we update. It’s understandable that Hydra cannot build everything, but it’s always bothered me that I have to pin nixpkgs if I want a build to stay functional over 1+ years. is mostly declarative. Of course, Julia is constantly re-compiling code, and until there is true support for precompilation, I don’t see how it’s possible to use nix store. This is due to multiple dispatch. Suppose I wrote a library to do an efficient k-nearest-neighbor query using some fancy free structure. Perhaps the core algorithms simply require a function for your types. When you write this new function, Julia has to compile all the code in the k-nearest neighbor library for this new type. Thus, it is not possible right now to compile a package on its own as the core pattern in Julia involves extending the function of other packages via multiple dispatch. You can only compile a package in context of the code that is running. Therefore, the Nix store approach is not appropriate. See
I see. You are talking about "authors" of Nixpkgs' expressions? I'm still a bit perplexed, as I earlier said, and correct me if I'm wrong: should fail if is used in , and the exact version is not available. Sometimes (), we do hardcode such version requirement changes in our expressions, but hopefully that's done only when it's justified.
Code change:
inherit (darwin.apple_sdk.frameworks) CoreServices ApplicationServices; }; <del> julia_15 = callPackage ../development/compilers/julia/1.5.nix { </del> <ins> julia_15 = callPackage ../development/compilers/julia/1.5.nix { </ins> inherit (darwin.apple_sdk.frameworks) CoreServices ApplicationServices; }; julia_1 = julia_10; <del> julia = julia_1; </del> <ins> julia = julia_15; </ins> jwasm =  callPackage ../development/compilers/jwasm { };

Related discussion:
text: I agree (maybe a bit ). Generally I think, every dep's version related issue should be handled by someone like you, who's familiar with python packages you use. I'd at least (open PRs) to fix the issues I encounter :). I see. I guess the situation is more complex than I thought, but I don't think I'd be able to form a strong opinion until I'll get a Julia interpreter from an expression I'm satisfied with. Thanks for the link :).
Unfortunately, this pattern is done constantly (including in my own contributions!). The problem is that, except an extremely rare cases like tensorflow, nixpkgs does not allow multiple versions of same python package to co-exist. Every time we update a package, we remove the previous version from nixpkgs. Confounding this issue, we often disable tests because sometimes the effort is just too high when developers bake in assumptions that aren’t compatible with the Nix ethos (for some reason this seems to happen more with tests then source code...). The most frequent cause of failure is the code needs to download something to run the test. (I’ve tried to lobby in the past that the test phase should be permitted to have Internet access as long as it doesn’t modify /nix/store, but I digress). In any case, the end result is that using a python package on Nix typically means you aren’t using the exact dependencies that upstream declared, and you’re more likely to have a package that despite having changes in dependencies has never had the test run. Thus, amazingly, I’ve had more luck with Julia packages working on NixOS than Python when all other binaries are present in environment.
I don't think there's a strong policy in our Python ecosystem against multiple versions of packages - if this is what upstream recommends. Anyway, the whole topic is out of scope for this issue. Feel free to open a new issue and cc me and who's working hard to ship a 20.09 release.
Yes, sorry getting a little off topic here. I mainly mention it to suggest that our efforts in Julia that start from scratch Can learn from these issues. I’m not too familiar with the new binary builder, but was quite nice in that it would first search for libraries before attempting to install.
Code change:
inherit (darwin.apple_sdk.frameworks) CoreServices ApplicationServices; }; <del> julia_15 = callPackage ../development/compilers/julia/1.5.nix { </del> <ins> julia_15 = callPackage ../development/compilers/julia/1.5.nix { </ins> inherit (darwin.apple_sdk.frameworks) CoreServices ApplicationServices; }; julia_1 = julia_10; <del> julia = julia_1; </del> <ins> julia = julia_15; </ins> jwasm =  callPackage ../development/compilers/jwasm { };

Related discussion:
text: See this issue for some context: Note that a core Julia dev gave a pretty great endorsement on Nix (albeit back in 2014): I think it might be most productive to do this development outside of nixpkgs, and do it in Julia to hook in with nixpkgs as needed. That way users could seamlessly use Pkg in Julia. I’d love to and have it just work instead of the current hack that I wrote that a lot of people seem to be using ()
Short summary of the Discourse thread: for LLVM and libuv it is essential to use the patches/forks. For other packages it is probably unnecessary to use the exact version specified by upstream.
Thanks for being there with me :). I think I'm gonna work on this once we are through with , to avoid merge conflicts.
TIL Guix manages to package Julia 1.4.1: What's interesting, is that they but they build it with Julia's LLVM patches fetched from the internet - they don't rely on Julia's build system to build it's own LLVM. For similar dependencies which the real system's version can't be used, they do the same. I think we should try to copy this approach.
FWIW I did that in Fedora originally, but I stopped. Since LLVM makes breaking releases very quickly, you'll probably want to move to a new version that Julia doesn't support quite soon.
Maybe I don't understand, but why should I move to an LLVM version that julia doesn't support? Also, aren't the and versions don't introduce breaking changes between minor releases? We could stick to since that's what Guix does and I think Julia uses this version as a base too.
I don't really know how NixOS works, hence the "FWIW". If you used versioned LLVM packages and keep older major versions then it's probably OK.
Just offering a user perspective: Julia provides a package manager that provides mostly reproducible (in a practical/scientific reproducibility sense rather than a bit-identical sense) environments easily from manifests. Increasingly, these environments are isolated from the host OS by binary packages for dependencies being served by Julia. I don't want Nix to manage dependencies that can handle for me: Julia already handles those excellently and conveniently. I just want Nix to handle the (usually few) system dependencies.
Code change:
inherit (darwin.apple_sdk.frameworks) CoreServices ApplicationServices; }; <del> julia_15 = callPackage ../development/compilers/julia/1.5.nix { </del> <ins> julia_15 = callPackage ../development/compilers/julia/1.5.nix { </ins> inherit (darwin.apple_sdk.frameworks) CoreServices ApplicationServices; }; julia_1 = julia_10; <del> julia = julia_1; </del> <ins> julia = julia_15; </ins> jwasm =  callPackage ../development/compilers/jwasm { };

Related discussion:
text: What I would like as a NixOS user is for Nix to provide me with a working Julia 1.5 derivation that provides: julia, a FHS wrapper or something providing compatible versions of the few things that Julia's binary packages need (just libc, libstdc++, libgfortran; I think. ). When I say "compatible", I mean that these libraries should work with the binaries and with the julia binary provided by Nix. Not all Julia packages are BinaryBuilder-ised yet, so I'd also want an easy way to specify that I want compatible versions of other packages installed (e.g. Qt, cairo, etc). For packages that need python, I don't know if I'd like Julia or Nix to handle installing and managing that. The simplest approach would be to tell Julia to do it (there is pretty good support in Julia for distributing isolated environments of python + packages + dependencies; better than in , imo). I don't know how doable any of that is in Nix, just describing what a good outcome would look like to me.
I think this is quite doable. I would propose that we add a new package, , that is a "batteries included" build that contains system libraries for all common Julia packages. Would this approach work for BinaryBuilder? I haven't used this yet. If not, we could fall back to a FHSuserenv, but I'm reluctant to do so if at all avoidable as there are outstanding nix bugs () that create seg faults in some heavy data processing workflows.
I think that is a good proposal and I think it will work with BinaryBuilder packages (e.g. SDL2_jll). In any case, some approach that works with BinaryBuilder packages should be found because those are a critical part of the Julia environment now :) Some important packages (e.g. GR) still want to build and install their own software dynamically, and that doesn't work well in Nix, but most of those can plausibly move to the BinaryBuilder system (PR for GR ), so I think letting those be broken would be tolerable (and a big improvement over the status quo of Julia on nix). Perhaps we can get something working quickly by just patchelf'ing the official Julia builds for now? (I don't understand how all of this stuff works!)
Code change:
inherit (darwin.apple_sdk.frameworks) CoreServices ApplicationServices; }; <del> julia_15 = callPackage ../development/compilers/julia/1.5.nix { </del> <ins> julia_15 = callPackage ../development/compilers/julia/1.5.nix { </ins> inherit (darwin.apple_sdk.frameworks) CoreServices ApplicationServices; }; julia_1 = julia_10; <del> julia = julia_1; </del> <ins> julia = julia_15; </ins> jwasm =  callPackage ../development/compilers/jwasm { };

Related discussion:
text: Is there anything presently blocking just getting julia 1.5 into nixpkgs? I don't care about ecosystem working with nixpkgs, just a good ol' fashioned julia install.
yes, see
If you just want Julia and don't mind about binary packages breaking you can just download Julia from the official site and patchelf it. On Sun, 4 Oct 2020, 09:32 Tyler Benster, <:
On the there was also the idea floated to patch to patchelf dynamically loaded binary dependencies.
Guix has a Julia package and it works quite well. Perhaps some ideas can be borrowed from there: It'd be really useful to get Julia working on Nix. It's the only big outstanding thing that doesn't work and prevents me from migrating some servers in my organization.
I tried to copy their expressions in and it doesn't work yet, but there's also another seemingly working attempt by at .
So, do we want anything else now that 1.5.3 is packaged (:greenheart: ? I think we: 't need clean up the expressions a bit - not use the file if it's not shared. I did (2) along with the julia_10 fix in As for (1) I will need a bit of feedback.
I guess some people like me still use julia_13 via test-disabling overrides, so a bit of time after 1.5 reaches channels for smooth transition could make sense?
Maybe backport 1.5 to 20.09?
OK so I disabled the tests for julia13 in and made the default there as well. All merged pull requests referenced here should be backported.
Code change:
, cmake , qttools , wrapQtAppsHook <ins> , qtbase , qtwayland </ins> , qtsvg }:

Related discussion:
text: low priority qt6.qtdeclarative is a large package, so it should be excluded for non-GUI qt apps () currently, when i build a package with and empty buildInputs, it pulls qt6.qtwayland qt6.qtdeclarative qt6.qtshadertools the problem is wrapQtAppsHook and its deps and qtwayland pulls qtdeclarative the problem is fixed by removing from deps wrapQtAppsHook should use only the declared buildInputs disabling wrapQtAppsHook (dontWrapQtApps = true) is no option, as also CLI qt apps need the qt wrapper qtwayland is there, so that users dont need to add it to buildInputs assuming that all qt apps are GUI apps im in favor of making this consistent with cmake so that all GUI apps must add qtwayland to buildInputs CLI qt app: GUI qt app: since cc
I'm in favour of this change, but the proportion of qt cli app night be relatively small, and it's not immediately clear that qtwayland should be if the build log yields Qt6::Widgets is missing.
Actually we are abusing qtwayland as a shortcut to bringing in qtdeclarative, this should be fixed too.
we could patch the cmake message to "please add qtdeclarative to your propagatedBuildInputs" the alternative would be to add a flag, but thats more obscure than buildInputs
Adding the lines to nixpkgs manual is sufficient.
By the way, is not only needed to pull in , but it's required for all GUI apps so that they work seamlessly on X11 or Wayland.
Code change:
<del> { lib , stdenvNoCC , fetchzip , fetchFromGitHub , butler , electron , steam-run , makeWrapper , copyDesktopItems , makeDesktopItem </del> <ins> { lib, stdenvNoCC, fetchzip, fetchFromGitHub, electron, steam-run, makeWrapper, copyDesktopItems, makeDesktopItem, </ins> }: <del> stdenvNoCC.mkDerivation rec { pname = "itch"; version = "26.1.3"; # TODO: Using kitch instead of itch, revert when possible src = fetchzip { url = "https://broth.itch.ovh/kitch/linux-amd64/${version}/archive/default#.zip"; </del> <ins> let version = "26.1.9"; butler = fetchzip { url = "https://broth.itch.zone/butler/linux-amd64/15.21.0/butler.zip"; </ins> stripRoot = false; <del> hash = "sha256-FHwbzLPMzIpyg6KyYTq6/rSNRH76dytwb9D5f9vNKkU="; </del> <ins> hash = "sha256-jHni/5qf7xST6RRonP2EW8fJ6647jobzrnHe8VMx4IA="; </ins> }; itch-setup = fetchzip {

Related discussion:
text: Package name: itch Latest released version: 26.1.3 Current version on the unstable channel: 26.1.3 Current version on the stable/release channel: 26.1.3 <!-- Type the name of your package and try to find an open pull request for the package If you find an open pull request, you can review it! There's a high chance that you'll have the new version right away while helping the community! --- The current version is broken since butler is marked broken Notify maintainers <!-- If the result shows no maintainers, tag the person that last updated the package. --Note for maintainers: Please tag this issue in your PR. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
The latest version on seems to be 26.1.3 which is used in the package.
There is 26.1.5 as a source code , but current package uses binaryBytecode
Code change:
va_end (ap); return res; <ins> diff --git a/src/builder-source-archive.c b/src/builder-source-archive.c index 3c694e57..0de62318 100644 </ins> --- a/src/builder-source-archive.c +++ b/src/builder-source-archive.c @@ -443,7 +443,7 @@ tar (GFile   *dir,

Related discussion:
text: Describe the bug flatpak-builder for some reasons can't use rofiles-fuse To Reproduce Steps to reproduce the behavior: build any app using flatpak-builder Expected behavior flatpak-builder should use rofiles-fuse. Screenshots Additional context Metadata system: host os: multi-user?: sandbox: version: channels(root): channels(piotrek): nixpkgs: Maintainer information:
installing solve this problem so maybe should be ?
We patch the paths to the executables to be hardcoded, so the program doesn't have to rely on something like ostree being installed. I believe one path isn't hardcoded with the current patch That looks it up in PATH, probably why it was working once you installed it.
cc
Thank you for your contributions. This has been automatically marked as stale because it has had no activity for 180 days. If this is still important to you, we ask that you leave a comment below. Your comment can be as simple as "still important to me". This lets people see that at least one person still cares about this. Someone will have to do this at most twice a year if there is no other activity. Here are suggestions that might help resolve this more quickly: for maintainers and people that previously touched the related code and @ mention them in a comment. on the . 3. Ask on the on .
should fix that issue.
Code change:
buildInputs = [ openssl zstd ] ++ lib.optionals stdenv.isDarwin [ zlib libiconv Security ] ++ lib.optionals (stdenv.isDarwin && stdenv.isx86_64) [ <del> Foundation </del> ( # Pull a header that contains a definition of proc_pid_rusage(). # (We pick just that one because using the other headers from `sdk` is not

Related discussion:
text: Steps to reproduce the behavior: nix on x86_64-darwin experimental features nix-command and flakes to install nushell v0.75.0 via . Please run and paste the result.
I can confirm the bug, the following PR could resolve it.
that is great news! I am hopeful that can resolve it. I see that you marked this as resolved by . However, this does not seem to have resolved the issue for me. I am still receiving the same error when trying to build :
The ofborg test did pass, see Maybe you have to build it on master? Also, I don't think will help, as the author of that PR.
Hmm, after upgrading nix and updating my nixpkgs-unstable channel, I'm still receiving the same error.
You have to wait for the commit to arrive on nixpkgs-unstable.
Thank you your PR resolved it. the fix is in the nixpkgs-unstable channel. Much appreciated!