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
In this situation, you can:
- Convince them to allow the usage of Nix (Uphill battle)
- Continue to use Nix locally, never pushing any Nix code
- Quit and work on a different project
- 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:
- 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.