I'm following along the tutorial to set up a dev shell and got as far as

{
  description = "A very basic flake";

  inputs = {
    nixpkgs.url = "github:NixOS/nixpkgs/nixos-23.05";

    flakebox = {
      url = "github:rustshop/flakebox";
      inputs.nixpkgs.follows = "nixpkgs";
    };

    flake-utils.url = "github:numtide/flake-utils";
  };

  outputs = { self, nixpkgs, flakebox, flake-utils }:
    flake-utils.lib.eachDefaultSystem (system:
      let
        flakeboxLib = flakebox.lib.${system} { };
      in
      {
        devShells = flakeboxLib.mkShells {
          packages = [ ];
        };
      });
}

on running nix run nixpkgs#nix flake check, i encounter the following error:

error:
       … while checking flake output 'devShells'

         at /nix/store/qkig73szmrhgp0qhncxy5vb36lw2g3jj-source/lib.nix:39:17:

           38|               {
           39|                 ${key} = (attrs.${key} or { })
             |                 ^
           40|                   // { ${system} = ret.${key}; };

       … while checking the derivation 'devShells.x86_64-linux.default'

         at /nix/store/0c36hfc4mdihdf87vm3kg14013vnzwi8-source/lib/mkShells.nix:22:3:

           21|   lint = mkLintShell { packages = lintPackages; };
           22|   default = mkDevShell cleanedArgs;
             |   ^
           23|

       (stack trace truncated; use '--show-trace' to show the full trace)

       error: attribute 'fileset' missing

       at /nix/store/0c36hfc4mdihdf87vm3kg14013vnzwi8-source/lib/flakeboxBin.nix:5:8:

            4| let
            5|   fs = lib.fileset;
             |        ^
            6|   fileSet = fs.unions [

Hi! love what you're building here.

I'm using this to achieve cross compilation from my x86 to a raspberry pi 4 (aarch64). While building works great, when I copy over the executable to my raspberry pi (also running nixos) and run it I get no such file or directory which indicates a problem with linking (according to my google searching).

Here is the file of the output:

❯ file result/bin/solver
result/bin/solver: ELF 64-bit LSB pie executable, ARM aarch64, version 1 (SYSV), dynamically linked, interpreter /nix/store/5gdh4mp8rwliq4s33gwcpwzqvsb2xpzr-glibc-aarch64-unknown-linux-gnu-2.38-23/lib/ld-linux-aarch64.so.1, for GNU/Linux 3.10.0, with debug_info, not stripped

And running ldd on the raspberry pi:

❯ ldd solver 
	linux-vdso.so.1 (0x0000007fb649c000)
	libc.so.6 => /nix/store/ilr14j6gzr9l651yb5w367y00cs6pflb-glibc-2.37-45/lib/libc.so.6 (0x0000007fb5ae0000)
	libm.so.6 => /nix/store/ilr14j6gzr9l651yb5w367y00cs6pflb-glibc-2.37-45/lib/libm.so.6 (0x0000007fb5a30000)
	libgcc_s.so.1 => /nix/store/x2f8wiip66lxf6zynscszpm4d990q098-xgcc-12.2.0-libgcc/lib/libgcc_s.so.1 (0x0000007fb59f0000)
	/nix/store/5gdh4mp8rwliq4s33gwcpwzqvsb2xpzr-glibc-aarch64-unknown-linux-gnu-2.38-23/lib/ld-linux-aarch64.so.1 => /nix/store/ilr14j6gzr9l651yb5w367y00cs6pflb-glibc-2.37-45/lib/ld-linux-aarch64.so.1 (0x0000007fb645f000)
❯ objdump -j .interp -s ./solver

./solver:     file format elf64-littleaarch64

Contents of section .interp:
 0270 2f6e6978 2f73746f 72652f35 67646834  /nix/store/5gdh4
 0280 6d703872 776c6971 34733333 67776370  mp8rwliq4s33gwcp
 0290 777a7176 73623278 707a722d 676c6962  wzqvsb2xpzr-glib
 02a0 632d6161 72636836 342d756e 6b6e6f77  c-aarch64-unknow
 02b0 6e2d6c69 6e75782d 676e752d 322e3338  n-linux-gnu-2.38
 02c0 2d32332f 6c69622f 6c642d6c 696e7578  -23/lib/ld-linux
 02d0 2d616172 63683634 2e736f2e 3100      -aarch64.so.1.  

While none of the dependencies are missing, it appears the interpreter is set to /nix/store/5gdh4mp8rwliq4s33gwcpwzqvsb2xpzr-glibc-aarch64-unknown-linux-gnu-2.38-23/lib/ld-linux-aarch64.so.1 (which is on my x86 system), and while ldd states this should link to /nix/store/ilr14j6gzr9l651yb5w367y00cs6pflb-glibc-2.37-45/lib/ld-linux-aarch64.so.1 it doesn't appear to do that when it runs.. Honestly I'm a bit out of my depth on this.

I'm wondering if anyone else has run into this and how it was resolved? It looks like statically linking is one option, but that is only supported by musl not glibc, which flakebox doesn't appear to support as the target is set to:

  aarch64-linux = mkClangToolchain {
    target = "aarch64-unknown-linux-gnu";
    ...

I suppose another option would be to ensure that /nix/store/5gdh4mp8rwliq4s33gwcpwzqvsb2xpzr-glibc-aarch64-unknown-linux-gnu-2.38-23/lib/ld-linux-aarch64.so.1 is indeed present on the raspberry pi system, but I'm not really sure how to do that on a continuous basis, I don't want to have to rebuild the system when I deploy my rust application to it

I also see that the intepreter is set to gnu-2.38-23 but links to 2.37-45 but if it were just a version change, why would it link to that in the first place?

ipetkov/crane#402 (comment)

crate-ci/typos#837

I'd like filtering source code to be as easy as possible.

Howerver currently the flakeboxLib.filter.filterSubdirs seems buggy for deeply nested dirs, and I'm not even sure what's the best API should be. Need to rethink.

will donate 100 USD equivalent in crypto in any currency for separate github flake repo.

https://fasterthanli.me/articles/my-ideal-rust-workflow

Lots of them we have already anyway, but worth looking through and making sure there's nothing good we're missing out on.

Hey, firstly, thanks for this tool; it's been of great help!

My issue is simple: I'm outputting 2 binaries from my Rust app and I want to not only expose both as packages but also have CI run on it (unsure if it doesn't though, I don't have many leads to debug this)

To avoid the XY problem, here's what I tried:

• I want to use nix run to be able to run the binaries of the app. But the flake.nix I got from running nix flake init -t github:rustshop/flakebox only output one package (at the time of running, my app did only have one binary so maybe that was the issue?). I want to be able to do something like nix run .#foo to run a specific binary. I've done this currently by manually adding a package output using pickBinary. This likely isn't ideal.
• Running any of the build variations like nix build .#ci.foo only work for the default package output and not my non-default package output. This makes me think that there's a much bigger integration issue at play here.

Still unsure if this is an issue with my setup/configuration or flakebox not supporting this OOTB.

Observed behavior

With

    # flake.nix ....
    devShells = flakeboxLib.mkShells {
        packages = [ pkgs.hello ];
    };
    # ...

> nix develop
> hello
The program 'hello' is not in your PATH. It is provided by several packages.
You can make it available in an ephemeral shell by typing one of the following:
  nix-shell -p fltk
  nix-shell -p fltk14
  nix-shell -p haskellPackages.hello
  nix-shell -p hello
  nix-shell -p mbedtls

Expected Behavior

Comparable to a Shell with

    # flake.nix ....
    devShells.default = crane.lib.${system}.devShell {
          packages = [ pkgs.hello ];
    };
    # ...

> nix develop
> hello
Hello, world!

Hey there, I have a question about cross-compilation with flakebox. It seems to work perfectly as long as you don't have any external pkgs dependencies.

If you do, you want to be using pkgsCross.<target> instead of pkgs for the buildInputs and nativeBuildInputs, but there are no easy way to specify that with flakebox's craneMultiBuild.

A hacky way to manually make it work for a target is to specify the target's pkgs in your flake with:

    pkgs = import nixpkgs {
      localSystem = "x86_64-linux";
      crossSystem.config = "aarch64-unknown-linux-gnu";
    };

To make the cross-compilation work, but of course this is now imposing the aarch64 pkgs on all targets, which is not the point.

Am I missing something or is that a limitation of flakebox?
I did take a look at flakebox's source to make it work, but it doesn't seem like a trivial change. My idea would be to accept a pkgsCross function for craneMultiBuild that would look like this:

          nativeBuildInputs = pkgsCross: [
            pkgsCross.openssl
            pkgsCross.sqlite
          ];

This would somehow be forwarded to mkStdTargets where the correct pkgs would be resolved and later passed to mkTarget.

Thoughts about it?

The CI job that gets set up when initializing a flakebox project depends on a lint shell being present, but that doesn't get set up by default: elsirion/fedimint-observer@8cc791a

Include a method to set it without room for typos.

On a freshly set up flakebox project I'm getting the following warning:

$ nix run
warning: Git tree '/home/elsirion/projects/fedimint-observer' is dirty
trace: warning: `overrideScope'` (from `lib.makeScope`) has been renamed to `overrideScope`.
trace: warning: `overrideScope'` (from `lib.makeScope`) has been renamed to `overrideScope`.
trace: warning: `overrideScope'` (from `lib.makeScope`) has been renamed to `overrideScope`.
trace: warning: `overrideScope'` (from `lib.makeScope`) has been renamed to `overrideScope`.
trace: warning: `overrideScope'` (from `lib.makeScope`) has been renamed to `overrideScope`.
Hello, world!

Probably benign and I might be holding it wrong, just mentioning in case this indicates a future hard error.

Hey there, really cool project!

I have a few nitpicks with the opinionated defaults of flakebox install:

• I might be using Gitlab and not requiring the .github CI
• I don't like git hooks and would prefer to disable them
• I may have a custom justfile and want to keep it over the flakebox default one

I'm asking if it's possible to make these settings opt-in via command line arguments.
Adding a prompt selection with y/n questions is also an option.

casey/just#1470

I'm following this tutorial: https://github.com/rustshop/flakebox/blob/master/docs/building-new-project.md

At the flakebox install step, I get the following error:

$ flakebox install
Error: project error
├╴at flakebox-bin/src/main.rs:228:39
├╴backtrace (1)
╰╴No flake.nix in project root directory

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

backtrace no. 1
   0: error_stack::report::Report<C>::from_frame
   1: <core::result::Result<T,C> as error_stack::result::ResultExt>::attach_printable
   2: flakebox::check_project_root_env
   3: flakebox::main
   4: std::sys_common::backtrace::__rust_begin_short_backtrace
   5: std::rt::lang_start::{{closure}}
   6: std::panicking::try
   7: std::rt::lang_start_internal
   8: main
   9: __libc_start_call_main
  10: __libc_start_main@@GLIBC_2.34
  11: _start

I want to cross compile to target:
aarch64-unknown-linux-musl

But using when a follow the get started tutorial and do a build with:

nix build .#aarch64-linux.dev.hello-flakebox a get a file of aarch64-unknown-linux-gnu

How do i declare the -musl part?

Running through the example and I got to this part:

flake.nix

{
  description = "A very basic flake";

  inputs = {
    nixpkgs.url = "github:NixOS/nixpkgs/nixos-23.05";

  flakebox = {
    url = "github:rustshop/flakebox";
    inputs.nixpkgs.follows = "nixpkgs";
  };

    flake-utils.url = "github:numtide/flake-utils";
  };

  outputs = { self, nixpkgs, flakebox, flake-utils }:
    flake-utils.lib.eachDefaultSystem (system:
      let
        flakeboxLib = flakebox.lib.${system} { };
      in
      {
        devShells = flakeboxLib.mkShells {
          packages = [ ];
        };
      });
}

➜  flakebox-test git:(master) ✗ nix run nixpkgs#nix flake check
warning: Git tree '/Users/tony/Dev/Rust/learning/flakebox-test' is dirty
error: a 'aarch64-darwin' with features {} is required to build '/nix/store/ay9qys7hlr73j73h84s5saracxclck59-flakebox-flakebox-ci-yaml-gen.drv', but I am a 'aarch64-linux' with features {benchmark, big-parallel, gccarch-armv8-a, kvm, nixos-test}

The instructions say: it means your nix is too old. Use nix run nixpkgs#nix flake check instead to run a newest version. With Nix even tools that are not currently installed are easy to use.

But I am using that, so I'm not sure what else could be the problem.