[gabyx]

Adds Nix packaging and flake export.

• Nix setup in tools/nix.
• just setup
• Symlinks to config files which "should" be toplevel (I mostly keep Git root as clean as possible) and our dev setup copies the relevant config files from tools/config into root only for certain LSPs needed. Otherwise no formatter files need to stay toplevel given treefmt-nix etc.
• [ ] Make this thing FAIR and contributable.
  • Format, lint, etc...
• Packaging with Nix in nix-release.yaml
• CI checks over Nix shell as more stable.

Assisted-by: no agent. Hand plugged.

[Panaetius]

This is way too much to just dump in a PR without any discussion. Especially since we only discussed adding a packaging step for nix so it can be used in nix projects.

Some of it is nice to have, like linting, but I don't know that we just want to adopt the current convention in eng team repos (e.g. where tool configs should go). Some of it seems like overkill in this repo (we don't need a whole docs folder for a tool with 2 commands). And I don't think we can just adopt a code of conduct or contributing guidelines without discussion in the team, especially if they contain placeholder values like alice.wonderland@sdsc.ethz.ch.

Could you just add the nix packaging/derivation step in CI like you originally intended?

[gabyx]

This is way too much to just dump in a PR without any discussion.

Jeah, I thought we had that discussion.
Dumping is probably an overstretch here. The changes are best effort to have some level of best practices in place without having others to commit to Nix. That was the agreement. This still holds I dont care how other people develop in this repo how they provide the toolchain. But I guarantee that the Nix DevShell works for everybody and its a no brainer just develop.

Look over the files and then lets clarify what you want changed and what the problem is.
As there is no consent obviously about some markdown files, I removed the whole docs folder.

Why the tools/configs -> root of a repo should be clean to collaborate.
A packaging step in Nix would technically not need a Nix devshell but you any way need one if you want people to just come in and test/build things... I need it anyway, can we keep it in? The setup will not really become any lighter if I take out the devShell.

Miri linting does not work and would need fixes, I disabled it for now...

[Panaetius]

The changes are best effort to have some level of best practices in place without having others to commit to Nix. That was the agreement.

What agreement? you asked if you could add a flake.nix and nix packaging setup in the repo, "best practices" was not mentioned once in our conversation. When you said you also want to add some standard files, I did not expect it to be this many. And this is from the SIS repo template, not something the engineering team uses or has had any discussion on. As such I feel uncomfortable just adding this in more and more repos, essentially forcing adoption on the engineering team, without any discussion within the team. If I were to go by the status quo on the engineering team, there should be a devcontainer, not a nix dev shell, and that only in more complex repositories, which this is not.

But I guarantee that the Nix DevShell works for everybody and its a no brainer just develop.

It doesn't for me as I don't use git and it fails on line 3 of the justfile with fatal: not a git repository (or any of the parent directories): .git 😉 but I'm a special case, so fair enough.

Why the tools/configs -> root of a repo should be clean to collaborate.

This is purely taste, I could just as well argue that the tools used/their config should be visible at a glance at the root of the repo, not hidden two folders deep where someone unfamiliar with this layout might miss them. Plus now there's editorconfig, envrc and gitattributes at the root, that's not very clean and arguably less relevant/more noise in a rust repo than rustfmt.toml and rust-toolchain.toml. What's the point of having them two subfolders deep to then have a command to symlink them to the root? That just feels like unnecessary extra steps. And in terms of best practices, having them at the root is what a majority of projects to, so principle of least surprise would put the configs at the root of the repo.

Why is there even gitattributes/git-lfs stuff? Git lfs is not used in this repo, there are no large files.

And there's other clutter. the whole scripts folder is superfluous, why add an additional layer of indirection instead of just having the commands in the justfile directly? They are only used in this one place (or in the case of lint-ub-rust.sh, not used at all). setup-config-files.sh is only needed because of the tools/config/ folder change, setup.sh only calls setup-config-files.sh, so neither of those has any reason for existing, except maybe "it might be needed later", which, well, then lets just add it later. I'm a big fan of adding things as they are needed, not front-loading complexity.

[gabyx]

Well, I understand your points. You also probably misunderstand that a PR is a suggestion. Either take it, suggest constructive changes or also refactor certain stuff yourself which doesnt fit "your-style" etc.

In general I do BoyScoutRule #1: Leave the camp ground cleaner then it was before.

• This repo was very basic and pretty raw in general.

• Not how we have been used to expose public repos in the ordes team. How you define stdandards in the engineering team -> well maybe that triggers a discussion and leave the PR open (repo structure, toolchain setup etc etc...)

• Of course one can always argument: its not needed now, its opinionated, its bloat, its this and that. Different people have different needs, my need is that somebody like Almut/me could jump in this repo and 'just build' it without having to rust-up - read through your missing how-to etc (be aware you are in the garbage land of python tooling with your maturin setup bindings and that is no way like "its simple and works" setup by the pure presence of python etc....
  Also I remind you that nothing of your CI is reproducible, good luck with other contributors trying to fix python/maturin problems...

As said again: I am not imposing a Nix workflow on the engineering team and also don't see this PR as pushing any standards of silently adopting "opinionated" structure (your initial structure by the way is also opinionated, its grounded by no decisions as well). Leave it open or refuse the PR, I do not care. Maybe this discussion should influenve the BPA documentation and guide standards how the engineering team wants things to happen.
Why is the justfile no dicussion, we could have argue till dawn if we not should use Go taskfiles or Makefiles or maybe bazle or pure bash or quitsh or chatgpt...

I kindly remind you that there is a reason why things are sometimes as they are: e.g. why the tools/scripts/lint-rust.sh -> this has the benefit of beeing a properly linted Bash file and not an inline unlinted unformatted justfile inline script. As always there is never a silverbullet. Git LFS is standard and if not done properly at start you end up with a not-good state when others add a picture etc etc...

• Where config files live -> probably not worth the effort to debate this. I ve seen too many repos where the root is completely bloated up contains up to 100 config files... your opinion and my opinion come from too different experiences and its fine. Maybe this PR should trigger a discussion on decisions how a general repo should look like and what is allowed where.

• setup-config-files.sh and the symlinking: sure I can remove that and just bloat the root folder, its fine for me...

It doesn't for me as I don't use git. Not sure what not-using-git has to do with a stable setup.
Feel free to add a devContainer. I will not use it, since a Nix shell is more robust.

P.S: eventhough I worked for years with devcontainers, I would suggest at least tooling that thing over a container which just has the Nix devshell inside, all other use cases over the M$ spec with the install hooks/layers is -> garbage tooling... and introduces more hidden logic/breakage then it solves... Its another non-optimal way of building an image...

For a fruitful collaboration on this repo I suggest, you point at what you would like to have removed and I try to iterate into this direction if it works. The above points are noted and I can adjust that.

[gabyx]

[devcontaienrs] and that only in more complex repositories

Completely disagree. Every repo must have an easy way to be able to contribute. Its not done by just dumping code into a Git repo and leave the setup to the contributor or reader...

That means:

• Formatting is in place treewide not like some stuff and others not.

• Proper toolchain providing is done -> container or Nix shell everything else is garbage and is not polite to the "reader"/contributor. mise btw is not a proper solution, its another tool which tries to solve again the same problems but way worse... I would generally suggest the eng. team should not dive into the field of "lets dockerize my machine to counteract 'it-works on my machine'", I know its the defacto std. way but suboptimal as nobody knows how to write proper docker files since nobody pins stuff and by that I also mean sudo apt update.

• CI must should be in place which handles the basic lint/build/test/image steps, if not -> the repo is not FAIR

(I am here to help in good faith, but if genuinely opposed due to what ever reasons (no or unfinished standards from the eng. team etc and personal opinions) I suggest you rather close the PR and I can call it a day.)

[Panaetius]

then let's leave this tabled for now. there are ongoing discussions in the eng. team, we had a meeting for a simple reproducible setup just yesterday for one of the repos, but have not decided on any approach, and I'd hate to introduce something before that discussion is settled.

[gabyx]

Ok, thats certainly welcome. Ah one point maybe to discuss:

• When is a repository "complex" enough to justify some tooling.

I have a stronger opinion on this: Cause I have mostly seen this argumentation when something starts and you say: ah we do not need CI or linting, its only a small this and that... and then 3 months later everybody feels its now quite "complex" and then stuff is missing. Certain things I would definitely not introduce later, for my taste introduce
For me the following should be given at start:

• the right repo structure (always make it the same everywhere, component based structures are best mostly since SDSC in most cases/projects does plug&play&research work which interconnects lots of technology and toolchains. If you only do a library for one language, then you take a simple language toolchain setup.
  @cmdoret knows about these...

• the basic BPA from the start, I would personally not give in into "ah its small, it does not need formatting etc".
  This includes questions: whats a general "good" tooling language (certainly not bash), either Go or Nushell. Since Eng. team already pushes for Go, I would say stick to Go with some helpers (maybe have a look at and what it provides).

  • Basic files (gitattributes, editorconfig, gitignore, ignore etc etc): See repo templates.
  • Basic tooling entry functions develop (devcontainer CLI, Nix develop etc) , build, lint, format, package (image, other stuff...).

• no readme explanations on what you need installed (this should be implicit by technology, Nix, devcontainers etc...)

• CI: Can wait and is easier to adopt when the above parts are clean and in place first.

If there is an eng. practice to that and templates and guides: its a no brainer and people start to do that automatically in the future.
Nix of course helps big time here, no matter if someone likes the technology or not.