Updated wayshot devel for NixOS

[Rishik-Y]

I Simply updated the development shell for NixOS to compile the wayshot program.
Seems like it hasnt been updated in a while?
I tried to compile the code using the flake.nix but seems like it doesnt work for me currently 😅
Correct me if i am wrong since i am quite new here but the dependency in code between now and v1.3.1 seems very different.

I could have added and updated dependencies with respect to current flake.nix
However I felt it would be difficult for beginners maybe who are starting off right now and wants to contribute (like me)
Plus I Myself mainly use shell.nix for my projects
So i just manually from scratch created a shell.nix and tested the dependencies one by one.

Hope its fine :)

[Shinyzenith]

Hi, We can't have hardcoded user paths in nix files. It needs to be general in nature.

Also I'm not very familiar with nix...I have stopped using nix for a while now.

[Rishik-Y]

Hi, We can't have hardcoded user paths in nix files. It needs to be general in nature.

Also I'm not very familiar with nix...I have stopped using nix for a while now.

Ahhh i see,
Will update the code to work directly with a url link instead 👍️

I have updated the code to remove Hardcoded user path to url link
Could you please confirm whether its fine now?

[Shinyzenith]

Hi, looks better now but I know very little about Nix.

@lavafroth can you look into this?

[lavafroth]

Looks fine. I recommend invoking the shell.nix derivation in flake.nix so it pins the depenedencies in a lockfile.

[Rishik-Y]

Hi @lavafroth,
I agree with you, However i kind of made this out of my use case and prefer using using nix-shell as my daily NixOS-devel,
However if you still want it in that manner i can make this a flake.nix instead 👍️

[lavafroth]

Yes, please do so. This will give the end user a choice for whether they wish to use a flake or the shell.nix way.

[Rishik-Y]

Hi @lavafroth,
I have tried and tested using flakes.nix
but Could you please check it once more?

Also sorry if i seemed rude before,
I just re-read it again, and it felt self-centored
So wanted to clarify myself that i didnt mean to dismiss you or anything, 🙇
Just wanted to reconfirm since i simply thought,
A guy who uses flake.nix as his rust devel would rather create his own customised deck then use mine.

[lavafroth]

Looks good. Thanks!

[axelkar]

There's a couple issues here:

• The Nix flake is impure. The flake could break at any moment when a new version of nixpkgs or the Mozilla Rust overlay is released.
• The overlay is not needed and just adds bloat. AFAIK the crate does not require nightly Rust, just Rust >= 1.85 for 2024 edition
• buildInputs and nativeBuildInputs should be separate. Add strictDeps = true; to validate for regressions like this
• Use rustPlatform.bindgenHook. It handles LIBCLANG_PATH and BINDGEN_EXTRA_CLANG_ARGS for you.
• Add rustfmt, clippy and rust-analyzer to the devshell.
• RUST_SRC_PATH = "${rustPlatform.rustLibSrc}"; Really simple when using Rust from Nixpkgs
• Don't include the compiler/linker (clang) in the packages as it's already brought in by mkShell

See https://wiki.nixos.org/wiki/Rust. The same goes for waycrate/xdg-desktop-portal-luminous#59

Should I update the flakes? I also have a Nix package definition for xdp-luminous

[Rishik-Y]

Hello 👋,
Thanks for pointing the issues

* The Nix flake is impure. The flake could break at any moment when a new version of nixpkgs or the Mozilla Rust overlay is released.

I actually agree with you, I personally don't prefer keeping my nix impure, However as discussed with @lavafrothThis will remove the need to update multiple files, multiple times replacing with updating one file instead.
Also I have been using Mozillla Rust Overlay (And other overlays) for quite a while, Havent encounter any issue where the nix devel got broke.

* The overlay is not needed and just adds bloat. AFAIK the crate does not require nightly Rust, just Rust >= 1.85 for 2024 edition

This is true as well, However At the time of this PR, I didnt know precisely how/what the development was heading towards, whether having the need to only use Rust >= 1.85 for 2024 or requiring something else later on for future development,
So keeping this felt, not causing much problem for current/potential nix users who would like to utilize nightly rust instead.

* `buildInputs` and `nativeBuildInputs` should be separate. Add `strictDeps = true;` to validate for regressions like this

Yep will do it in future PR

* Use `rustPlatform.bindgenHook`. It handles `LIBCLANG_PATH` and `BINDGEN_EXTRA_CLANG_ARGS` for you.

Yep learnt about it just 2 weeks ago, can use it.

* Add rustfmt, clippy and rust-analyzer to the devshell.

Yep, Will definetly add that.

* `RUST_SRC_PATH = "${rustPlatform.rustLibSrc}";` Really simple when using Rust from Nixpkgs

Redirecting back to overlay, Overlay already adds its own src Path. (obv depends on the overlay as well)

* Don't include the compiler/linker (`clang`) in the packages as it's already brought in by `mkShell`

I actually didn't know about this, Does that mean we would have to include clang only during packaging?
Since iirc I needed to specifically get clang lib to make it work for a certain package.

See https://wiki.nixos.org/wiki/Rust. The same goes for waycrate/xdg-desktop-portal-luminous#59

Should I update the flakes? I also have a Nix package definition for xdp-luminous

I am still somewhat of a newbie as i have only been using nix for past 3/4 months, so
Please go ahead, If you believe it would be more beneficial than the current flake.nix.

[axelkar]

Hello 👋, Thanks for pointing the issues

I already filed a PR for xdp-luminous, and I plan to add it to other waycrate repos waycrate/xdg-desktop-portal-luminous#64