Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Flake templates #188

Open
wants to merge 3 commits into
base: master
Choose a base branch
from
Open

Conversation

ScratchCat458
Copy link

In response to issue #119.

Adds a new example to the examples folder that provides a flake with a dev shell with the default stable toolchain and allows use on multiple systems via flake utils. Based on this README example.

Template can be initialised with:

nix flake init -t github:oxalica/rust-overlay

I'm considering creating another template that uses a rust-toolchain.toml instead, but I will save that for another pull request.

@oxalica
Copy link
Owner

oxalica commented Sep 16, 2024

I personally cannot get the point of flake template until it gets anything more than a fancier cp -r. It does not even support configuring name, let alone custom checks and file appending. Guessing user's demand is hard, even providing multiple templates cannot make up the inability of cp -r.

  1. Is user already having a Git Repository and/or a rust package, just want to initialize the Nix part? Does .gitignore exists and target ignored?
  2. Is flake.nix and/or shell.nix already exists? Which approach does the user prefer? I'm a fan of flakes, but I still find shell.nix more light-weight and more convenient for simple cases. It's fast and does not copy the whole directory into nix store after each modification.
  3. Does the user want to use rust-overlay for building and/or packaging in Nix, or for development, or both? For packaging or CI, I'd say the best practice is to have 3rd party tools like naersk or crane to cache dependencies, but I don't want to endorse them and add them as "default template". Same thing for flake-utils, flake-parts and many other structure helpers. You may want them in some (or many) cases, but adding them into template is not a good way to introduce them.
  4. Cross compilation is also a hard part. The different between targeting aarch64-linux and riscv64-linux may not be just a string change. (Through, in most cases, they are; unless the user is not in the set of "most cases")

I prefer adding more examples if user want something for reference, than flake templates for directly cp. Or maybe you have better knowledge on "what a most useful template for most users is like"?

@ScratchCat458
Copy link
Author

Nix's templates are somewhat limited in what they can provide due to a lack of granularity. There has been some ideation, but its mostly a dead end. I agree that Crane is probably the best option for most users to setup shells alongside packaging.
There is no real consistency across the templates of different repos, some initialise the entire project, others only create the flake. For most users, a nix flake init is usually desired as a replacement for a quickstart. I can definitely see the difficulty in providing a template that satisfies most use cases for a lower-level tool like rust-overlay, especially after considering cross compilation.

Sorry that I can't really provide a satisfying answer.

inputs = {
nixpkgs.url = "github:NixOS/nixpkgs/nixos-unstable";
rust-overlay = {
url = "github:oxalica/rust-overlay";
Copy link

@holly-hacker holly-hacker Sep 17, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

For stable toolchains, you can do

-      url = "github:oxalica/rust-overlay";
+      url = "github:oxalica/rust-overlay/stable";

I believe this reduces download size, but haven't checked lately so can't tell you for sure.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

True, stable branch would result in a smaller download size as the manifests for any nightly versions released since the latest stable would not be included. However, the download size reduction is insignificant enough that it wouldn't be worth increasing the complexity of reading the template for new users.

Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

For stable toolchains, you can do

-      url = "github:oxalica/rust-overlay";
+      url = "github:oxalica/rust-overlay/stable";

I believe this reduces download size, but haven't checked lately so can't tell you for sure.

I didn't explicitly document the stable branch because I have not decided what's the goal for it. Please do not use it for production. Currently, It's just updated less frequently but with the same content (so the same size).

in
devShells.default = mkShell {
buildInputs = with pkgs; [
rust-bin.stable.latest.default

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

For a dev shell, wouldnt it be useful to also include rust-analyzer and rust-src?

-            rust-bin.stable.latest.default
+            (rust-bin.stable.latest.default.override {
+              extensions = [ "rust-analyzer" "rust-src" ];
+            })

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Unsure on this one. How useful this would be to users depends on how they have their IDE and system configured. On NixOS this might make more sense. For users on other distributions which use Nix for a specific project, they may have their language servers installed globally (e.g. system package manager, rustup) or by their editor (e.g. VSCode extensions, mason.nvim) which may not pickup an LS in the local environment. Worth including in further discussions about what templates for rust-overlay should be/include.

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That's fair, though I'm not sure what the point of a rust devShell would be if rust is already installed globally.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Many people prefer using/creating dev shells for open source stuff to lower the barrier of entry to hacking on the project, by removing the need to globally install tools and preventing the dreaded "It works on my machine" problem. They also help ensure the same (versions of) tools are used in development, CI and packaging. Dev shells are still useful for personal projects for these reasons, but their true potential shines when used by multiple people or across many machines.

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I know what the point of a devShell is 😅 My point was that a devShell isn't needed if rust is already installed globally, especially with rust having almost perfect backwards compatibility (even more so on stable releases as is the case here). This is also a devShell, it doesn't build a package or anything.

I'd agree with you if this was a non-trivial devShell that includes dependencies (eg. pkg-config, openssl, some specific dev tooling, a specific version of the rust toolchain), but this is just a template where people can build upon. People can remove the extensions they don't need after creating it, and it also serves as an example.

Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

but this is just a template where people can build upon. People can remove the extensions they don't need after creating it,

No they wouldn't. Most of people will copy code from internet, check if it compiles(evals), and then keep it forever without a second glance. ChatGPT hype and sshd-depends-on-systemd (JiaTan's supply chain attack) all taught us that. I'm against making a "template" too big and/or too complete.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants