Workplace won't let me check in `.nix` files. What are my options?

Help
1

The Rust team at my workplace won’t let me check in .nix files.
The SDK we are using doesn’t work well with Nix because there are some impure stuff that needs patching. So they use a normal distro and install the stuff globally.

I need to install libraries like openssl globally so that projects like this can find them.
But apparently if I install it using home-manager, it won’t be found by pkgconfig.
I need to put it in flake.nix/devShell for it to be found.
My current approach is to have a flake.nix locally gitignored.
Are there any other options?

Ideal scenario I can have a centralized flakes folder and inside it I can have a flake.nix for each project, so that I can upload it to a personal repo. Is there a way to achieve something like this?

2

You can have the flake.nix anywhere on your filesystem and use nix develop ~/where/your/devshell/lives for example. The only tricky bit will be telling it where the source for your application is, if you also want to do a nix build and not just nix develop. For that you’d need to add your work project as a flake input like inputs.work.url = "path:/absolute/path/to/work";.

3 Likes
3

I have a flake.nix, flake.lock, and .envrc ignored via .git/exclude or how that was called (as mentioning in .gitignore per repo is not allowed as well) and use them via direnv and use flake path:$(pwd).

3 Likes
4

You can make the ignores global, too, if you don’t want to remember to add an exclude file to each repo (explicitly using git add overrides that I believe): Git - git-config Documentation

1 Like
5

A previous employer wouldn’t let me use Nix either, and also lectured me quite often about how it was a company decision to use other tools like Yocto/Bitbake, Docker, etc, each time that I tried to use it. I quit that job. Now I’m working with a team that contains some people who don’t necessarily want to use Nix, and try to circumvent Nix by using Docker occasionally. Our gitignore file looks like this:

# Dockerfiles, or docker-compose files are not how we build or deploy software.
# Only Nix expressions are allowed.
*Dockerfile*
*docker-compose*

# Github Workflows are not what we use to perform CI, we use Hercules-CI
# instead.
.github/workflows

# There's a habit of putting random shell scripts into a folder named 'bin' or
# 'ci' at the root of the Git repo. Shell scripts should, in most cases, not
# exist in this repository.  Scripts should be encoded via nix, by being added
# to the `apps` attribute of the flake.nix, and ran via `nix run`.  This way,
# they work every single time and do not depend on the environment where they
# are ran, or require the user to install any additional dependencies.
bin
ci

So in summary, you should consider working with people you want to work with, and who have the same viewpoint on software development, rather than trying to force people who don’t value reproducibility, or the same principles that you do.

3 Likes
6

I think it’s fine to ask people not to pollute .gitignore files with stuff that is never actually produced by the project in question. That’s exactly what the .git/exclude file is for; things that pertain to your own personal development workflow.

That’s different from demanding I use a specific tool (“we only use manual screwdrivers here, go away with your powertools”), which I don’t think is the problem OP is having here.

As much as I agree that everybody should just use nix, it’s a little rude to pollute projects that don’t currently use it with artefacts of my personal setup - it’d be a shame if I couldn’t contribute to open source projects while using NixOS because I have to include my own gunk in their .gitignore files.

I’d consider everything in that gitignore you shared unnecessary noise in a nix repo too, though, and would reject any PRs trying to add those lines (pointing the person making them to .git/exclude instead, and maybe a wiki entry about their setup).

5 Likes
7

I am only expressing an opinion here, and I was motivated by the title of the thread and was reminded of my own situation with a previous employer. What I’m saying primarily applies to working on a closed-source project with a team that have already made decisions about tooling.

and would reject any PRs trying to add those lines

It wastes my time to review a PR and reject it, and it also wastes the person making the PR’s time working on adding code that is destined to be rejected, so I find that the .gitignore file with comments makes it adequately clear why stuff is blacklisted, as well as preventing people from doing work and being disappointed, especially in a team of 20+ people where this is not always communicated efficiently or effectively through PRs alone.

The Rust team at my workplace won’t let me check in .nix files.

In this situation, you can:

  1. Convince them to allow the usage of Nix (Uphill battle)
  2. Continue to use Nix locally, never pushing any Nix code
  3. Quit and work on a different project
  4. Stop using Nix altogether and work with the upstream decided tools alone

I do not see how 2 is sustainable, and I don’t believe 1 or 4 are fun, specifically when working on a closed-source project.

If you continue to use Nix secretly in private, you’ll just rub up against issues that everyone else in the team are not experiencing. You now have 4 platforms to worry about:

  • Windows
  • MacOS
  • Normal Linux Distros
  • NixOS (Very special and has issues that the others don’t because it cares about reproducibility)

For this reason, a lot of companies, teams, etc settle on Docker as the standard platform. In my team, we settle on Nix. If anyone is avoiding the usage of Nix or Docker in this example, we suffer from “Works on my machine”. which puts us back to square 1.

In the case of this thread, the system that has been settled on by the team as the standard (I assume) is cargo. And Cargo is pretty good, so it’s not so bad. Using Nix is just putting a cherry on top.

I like Nix too much, so I chose option 3, and never looked back.

3 Likes
8

Why do you need to use flakes? Having a personal repository with a bunch of nix files is much simpler with plain environments indended for nix-shell which you can then use from anywhere using nix-shell /path/to/project-shell.nix without too much hassle.

3 Likes
9

Personally, I find the small performance improvement from evaluation caching is nice when using direnv, but that is indeed another nice alternative.

3 Likes