I don’t know where to report the issue but I once installed Nix on a corporate Amazon workspace and there were inconsistencies because the user that was assigned to me was part of some kind of ldap or active directory (I don’t remember really well sorry)… and it contained backslashes.
I also remember that Nix has some troubles to deal with usernames containing backslashes.
@drupol Please check for duplicate installer issues and otherwise open a new one. The workgroup should monitor that GitHub label to keep track of pain points.
Thanks to everyone involved in the meeting, it was really great to all sit around and discuss this. The notes are (still) here, or in the spoiler below in case the document disappears:
Notes from meeting #1
Agenda
Round table to get the different expectations from the installer
Presentation of DetSys’s experimental installer
Pre-meeting notes
Notes from @domen:
document the difference between single/multi user install and the decision that the user needs
merge 4-6 scripts that create the installer so that the logic is centralized (right now each script has a different syle, functions, etc)
installer should be idempotent
there should be an uninstaller that works (this is mainly not to gain Nix haters)
create automation to test the installer on many platforms, especially for the new ones (macOS)
Notes from @Solène
The installer has issues with Linux systems using SELinux.
Having an official standalone nix binary would also be awesome, I count this as “installing” because it’s a non-installation case.
For the upcoming tools abstracting nix usage, namely:
devbox
riff
bob
a more “lightweight install” could be beneficial. The nix install can feel a bit “intrusive” for some users when the entire nix tool chain is installed. Also avoiding changes to the users environment would be beneficial. Not sure which part’s could possibly be left out.
We should minimize the amount of code duplication / divergence between different installation paths, e.g. daemon vs non-daemon, bash vs. fish.
The best way to simplify the installer is to minimize the amount of work done by the installer, i.e. have more defaults in Nix or Nix auto-creating directories.
Even better is if you don’t need to install Nix at all, e.g. by using the auto-chroot statically linked nix binary.
Meeting notes
Round table
Ana
Determinate Systems (DetSys)
No strong opinion on what the installer should do, just wanna work on it
Chris
Tweag
Same thing mostly
Onboarded a couple friends, nearly everyone got bitten by some installer quirk
Travis
Suffers for people encountering install issues
Worked on some MacOS-specific issues on the installer.
Needs testing, testing , testing
Alexander
RedHat (unrelated to Nix)
Install on Fedora is… interesting
Heard about SELinux issues
Solène
Tweag, part of the Nix group
Learned about the installer issues only recently because exclusively uses NixOS
Interested to help with testing
A standalone binary could be great too
Graham
Determinate Systems
Talked about that for a few months at DetSys
Installer is bad
Uninstaller doesn’t exists and the instructions are scary
Started to reimplement the installer in the last couple weeks
Matthew
Flox
Not fetching a random script from the installer
Make it more “pure” because it’s a bad intro to the ecosystem right now
Eelco
Determinate Systems
Used to have an automated installer test in the Nix testsuite, but deprecated
Revived it with Graham’s matrix installer test
The installer should do less stuff (like not having to create all the build users)
Extreme form of that: Standalone statically linked binary
Théophane
Tweag
Installer is the entrypoint to the ecosystem for most people. So it needs to be perfect
DetSys installer
Just uses bash to bootstrap the actual installer which is a compiled binary.
Demo
Rust binary
Idempotency
The installer is doing a lot of things that should all be reversible
Should save the exact steps that have been done somewhere so that it can be rolled back (or replayed, or shared)
Architecture:
Fetch a (bash) script that does some feature checks then fetches the binary installer for the current platform (could adapt the Rustup wrapper script for that)
Currently very opinionated
Will switch flakes on by default
Only uses the daemon
Single-user install?
Not supported by DetSys installer. Because they feel that single-user mode is not a good experience and makes the ecosystem less uniform (so the userbase more complex).
How useful is the single user install?
Docker containers (because no nested sandboxing)
No-systemd systems
Security-constrained envs
@Solène offers to create a discourse poll to get a sense of how much it is used
WSL?
Can run systemd (even NixOS there), though in a hacky way
Technically uses its own init system, might be worth having a dedicated support for it
Installer language
Having a binary installer means running a binary blob, while a bash script is somewhat more introspectable.
But people will run a precompiled Nix anyways, so that doesn’t change too much.
And the benefit of having a proper language over bash outweights this by far
Distro packaging
Ubuntu has it (slightly outdated) in its repos, which is great
Rust gave up on that
nix-community has rpms
Having stuff on distro’s repos is a lot of pain.
Having Nix packaged as a deb/rpm is simpler, and makes people more comfortable, and we avoid the problem of having them outdated in the repos.
To be discussed later.
Testing
The installer should test itself at the end to make sure that stuff is available in the user’s shell
Manage the expectations. If people have a weird system that prevents the installer from working, it must be made explicit so that they know it
Future steps
Follow-up meeting in 2 weeks (Sept. 28, 16:00 CEST)
We just finished our third meeting, thanks folks for attending! we talked some about the installer DetSys is working on, and what sort of acceptance criteria there would be for the greater community to want to use it. We decided to not get too far into details, as we can become more specific once we have an MVP out.
Another meeting today, TLDR is the installer is getting polished but it still require some work especially for MacOS (while WSL has been painless).
I would like to thank @grahamc for taking the following notes during the meeting:
2023-02-01
Agenda:
Release
soft release with zero to nix to avoid saying it is ready-ready
learned a bunch of stuff about APFS volumes / persistence
postponed to February 24, but might move it up
rename it again
Upcoming work
Deleting the nixbld users on macOS.
Not excited about releasing without deleting the created users.
Potentially want to take advantage of the auto-uid-allocation feature?
Needs testing & verification before putting it to users.
WSL
What’s missing to have parity with the upstream installer
No single user install support
Looking at a root-only installation mode.
Architecture support
i686-linux support would be nice, and plausibly a blocker for upstream
Ana is making a ticket.
Questions / Todo’s
Does the uid/gid allocation try to detect conflicts?
not today
→ bug report
Let’s document that you can install NixOS on any aarch64 pi (todo: list)
but only install Nix using this installer on pis running an aarch64 OS (todo: list)
Does the installer workgroup see itself as having a stake also in NixOS installation under WSL? I think it’s an important use case and it seems related to the big picture of Nix onboarding.
I use it at work, and it’s great. If anyone involved in this has the bandwidth to help nudge it along on its way to the Microsoft Store , that might be great for introducing many developers and sysadmins to NixOS in an undemanding way.
Neither nixpkgs or NixOS have good 32bit support and only dependencies of wine and the steam fhs are truly tested and fixed AFAIK. Before 32bit support for the installer is advertised the support state of 32bit should be clarified. I myself would not consider missing or removed 32bit support any kind of blocker in a PR for a lot of packages right now.
Maybe we need to make a symlink in /usr/bin or ``/usr/local/bin`?
/usr/local/bin appears to be writable by default, and is in PATH by default: /Users/ephemeraladmin/.nix-profile/bin:/run/current-system/sw/bin:/nix/var/nix/profiles/default/bin:/usr/local/bin:/usr/bin:/usr/sbin:/bin:/sbin
What does Theophane think is the most right thing to do, re: upstreaming the DNI?
nobody really understands the current installer / touches it except reluctantly
does Nix want to maintain their installer, or adopt the DNI?
Theophane is in favor of upstreaming, since it is technically superior, even though it doesn’t support some use cases.
unsupported cases:
single user mode, probably the biggest case
could fall back to the current installer in cases it doesn’t work
what comes from non-trivial bugs / regression reports?
Travis: generally in favor of this as well.
Are there major regressions or feature gaps? Are these feature gaps problems that need fixing?
Ana: any problem with the fact that DNI is in Rust?
Theophane: no
Travis: Bash is popular, but it isn’t helping us get quality contributions
Theophane: does make bootstrapping problems more complex, but this is not strictly an issue for the installer
Travis: If there is a downside, it isn’t end-user hackable.
For example: a user could download the installer and hack in a new UID or whatever… which may mean that user is less likely to contribute an upstream fix
Ana: would the Nix project want to upstream the backend that takes the backend which redirects based on branches and PRs?
Theophane: unclear, DNI is useful with just S3 or whatever
Travis: should the installer work with older versions of Nix?
Ana: We don’t now, but potentially we could?
Theophane: currently its tied to a specific version
Graham: would rather not take on the technical complexity needed to support many versions of Nix
Graham: Who gets to choose? What’s the process?
Theophane: trusts your judgement to decide…
Who is going to make the effort to do it?
Travis:
intermediate step makes the current URLs continue to work as-is
start pulling the Rust version in as a non-primary version
encourage people to start testing the Rust version … in the event they’re having trouble.
Théophane: What would upstreaming look like from the Determinate Systems side?
DetSys would probably keep its own version as a way to freely experiment and keep it opinionated
Upstream would be a fork of that installer
The Nix org could also use the public rust library and create a modified version of the DNI
A peculiarity of the DNI is that it sends automated reports on installation failures. That probably wouldn’t work for upstream, and cause the DetSys version to be aware of some problems earlier
Travis:
Automation could automatically send patches from the DNI repo to a Nix installer repo
Matthew:
Long term, who is maintaining the Nix version of the repo?
Theophane: Installer WG would be a good fit
Next Steps:
Theophane to check with the Nix team to:
officially say they want to experiment with it.
Create a fork under the NixOS org and produce binaries, made available at a convenient “official” URL which is not the main installer URL
Recommend using the Rust installer experimentally, or as a fallback if the bash version doesn’t work.
???
Install nix
TLDR next steps for the DetSys installer are:
Theophane to check with the Nix team to:
officially say they want to experiment with it.
Create a fork under the NixOS org and produce binaries, made available at a convenient “official” URL which is not the main installer URL
Recommend using the Rust installer experimentally, or as a fallback if the bash version doesn’t work.
As a nix-installer user, I have been hacking with the DeterminateSystems nix-installer lately. Is there anyway I can join these meetings live? Where I can get the schedule of next meeting?
Please thank Hoverbear (and everyone else involved at DS) for all the hard work regarding the installer. nix-darwin does not play nice with it but their work is much appreciated!
Regarding that and the recent success of the detsys installer, is there a tracking issue for replacing the current installer with a fork of the detsys one? I’ve seen talks about this being done and also heard that there are some changes that have to be incorporated before it can happen, but didn’t find anything on our issue tracker.
Since we haven’t been posting updates here, I’ll summarize a bit.
Work to implement changes requested by the Nix team has been done for a while now and we were working towards an initial release in May and early June, but the macOS Sequoia update breaking existing Nix installs took priority until several weeks ago.
AFAIK outstanding work at the moment looks like:
Finish WIP sync-up with upstream (covering roughly versions 0.19 to 0.27). I have a WIP conflict resolution up on a branch, but it poses fresh decisions that Matthew and I still need to work through.
Work out basic initial release process. Infra team expressed preference for us to just release via GH rather than push to S3.
Poke infra team to point some official obviously-experimental URL under nixos.org at the released installer.
Start some as-of-yet undefined process of giving project stakeholders ownership over the path forward, here.
notes for 2024-11-06
Travis found time since last meeting to pull together WIP merge to sync up with upstream as of post 0.27. Conflict resolution posed fresh decisions we need to sort out.
Matthew hasn’t had time to look at WIP merge or release process yet.
Tom requested meeting notes and a general update.
Cole reported on Matrix that upstream is getting confusing issue reports against their repo from people trying to install the “prerelease” of the experimental installer
Domen set this up for the project early this year and included in the devenv installation instructions. It uses a workflow to commit installer binaries on the prerelease branch.
This depends on our Hydra jobset, which we inadvertently disabled during conflict resolution in the May sync-up, though enabling the jobset alone didn’t fix the issue.
We debated whether to put effort into debugging this (potentially distracting us from merge and normal release process), ask Domen to do so, or just defer worrying about this.
Cole likely saved us from this decision by spotting the probable bug in the Python script responsible for the release.
After meeting: Travis committed/pushed this fix. It looks like this worked, but the broader workflow now fails when it tries to check out the prerelease branch. (Whenever the workflow was first run, the prerelease branch didn’t have the binary files. Now that it does, there’s a conflict with the freshly-generated files when the git-auto-commit action tries to switch to the branch.) Punting to Domen on this.
