-
Notifications
You must be signed in to change notification settings - Fork 59
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
Support remote-building to macOS hosts #714
Conversation
Our README has long featured a snippet to add to the zshenv, with a caevat that it might behave strangely if you're writing a script with an empty PATH. It is pretty straightforward to eliminate those caveats while still providing remote building for Nix to macOS hosts.
README.md
Outdated
@@ -267,6 +267,8 @@ While `nix-installer` tries to provide a comprehensive and unquirky experience, | |||
|
|||
### Using MacOS remote SSH builders, Nix binaries are not on `$PATH` | |||
|
|||
*For Nix installations before Determinate Nix Installer version 0.14.1.* |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This part can be removed, we do not need to document old niche problems in the READMEs of new ones. I suspect we could look into cutting a new release quite soon, even.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We might should keep a list of problems and quirks of old releases. Like the below note about nix-darwin should be solved now, now?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The old releases have their own READMEs with quirk lists! :)
In the nix-darwin
case, users may still try to uninstall Nix on their own before trying to use this tool, and we might get it wrong. We should be able to remove it if we implement a correct fix though.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Cool!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for jumping on this so quickly! It's a neat approach :)
One corner case I've encountered in the past with the DetSys installer, which this also doesn't cover, is if the user sets their login shell to bash. Not sure if that's common enough to worry about, but I figured it's worth mentioning either way.
@lheckemann Hrm. Good to know ... let's see ... |
@lheckemann Do you have any suggestions as to how to fix that? /etc/profile isn't loaded for that, and I'm not sure what else to try based on a skim of the bash manpage. |
It works! 🎉 |
Co-authored-by: Ana Hobden <[email protected]>
Good point, it looks like the only thing it'll source when it's neither a login shell nor interactive is the file pointed to by |
Our README has long featured a snippet to add to the zshenv, with a caveat that it might behave strangely if you're writing a script with an empty PATH.
It is pretty straightforward to eliminate those caveats while still providing remote building for Nix to macOS hosts.
Description
Checklist
cargo fmt
nix build
nix flake check
Validating with
install.determinate.systems
If a maintainer has added the
upload to s3
label to this PR, it will become available for installation viainstall.determinate.systems
: