-
-
Notifications
You must be signed in to change notification settings - Fork 158
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
[RFC 0011] Per project config #11
Conversation
ef5f2ba
to
33977ed
Compare
33977ed
to
c581b70
Compare
-1, what speaks against using plain shell scripts?
|
So I need a new script for |
So this is basically what direnv with the nix integration currently does. |
I don't think so, does it? This is about setting options for nix itself. |
Yes, you are correct, I did not read carefully enough. |
Normally these should have a way to forward relevant options if necessary.
Exactly this, so I don’t see why we need to increase the nix codebase with this functionality, apart from making nix invocation suddenly depend on additional files (that may be out of the user’s direct control). Combined with |
I don't see how scripts actually solve this. For my project that uses a custom hydra, I need a separate script for nix-instantiate, nix-build, nix-store, and nix-shell at least, plus I need to modify nix-buffer to be able to pass an option flag based on the current directory, plus I need to tell all users that they need to use the scripts instead of the tools they're used to when working with nix... |
And again, this is completely orthogonal to direnv. |
I strongly suspect there’s a better solution to your specific problem.
That’s valid, yes, but I think it should be solved in a way similar to As a general gripe with this RFC (and RFCs in general): Not having at least three practical examples on how the proposed feature would look and play out makes me very suspicious it has been thought out very well. |
What is it? I've been dealing with this problem and ones similar to it for over 5 years of working on nix based projects and this is the best I've seen.
Can you expand on that?
There's no section in the RFC for practical examples, but that doesn't mean I don't have any... I could provide several if you think it's relevant. If you disagree with the utility of this feature, fine, but it is well thought out and does solve a real need I've had multiple times, even if it's not the ideal solution. |
Also, in case this wasn't clear, if this is merged in it never has to affect you, just don't set |
Some real cases this would have improved:
|
I haven’t thought it through exactly, but in my experience the
I’d argue there should be one for an RFC to be complete. Means there is a mockup to be developed against. The examples should act as acceptance tests. |
Open a PR 😄 |
[unresolved]: #unresolved-questions | ||
|
||
Is the path nix is operating on determined by the current working | ||
directory or the path of the nix expression(s) it's evaluating? |
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.
If the latter were implemented, how would this feature interact with import
? Consider that when building a NixOS configuration, the "entrypoint" is not your configuration.nix
but rather $NIXPKGS/nixos/default.nix
. So if import
s wouldn't trigger reading nix.conf.local
s, then this feature wouldn't work with NixOS configurations without forking nixpkgs into the project direrctory.
On the other hand, the thought of nix config options changing in the middle of the evaluation after an import
sounds like a massive headache.
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.
Right, yes. I'm pretty sure current working directory is the only sane choice.
It would be nice if the channel could also be selected. Pinning nixpkgs per
repo for nix-shell scripts is not that straight-forward.
…On Sat, 8 Apr 2017, 23:39 Shea Levy, ***@***.***> wrote:
***@***.**** commented on this pull request.
------------------------------
In rfcs/0011-per-project-config.md
<#11 (comment)>:
> +execution.
+
+# Alternatives
+[alternatives]: #alternatives
+
+Currently, we must manually switch our option sets per project as
+appropriate, or try to find a global set that works for most cases. If
+one of those cases requires
+`allow-unsafe-native-code-during-evaluation`, there is a temptation to
+just set that globally.
+
+# Unresolved questions
+[unresolved]: #unresolved-questions
+
+Is the path nix is operating on determined by the current working
+directory or the path of the nix expression(s) it's evaluating?
Right, yes. I'm pretty sure current working directory is the only sane
choice.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
<#11 (comment)>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/AAAMsDaSYSF3Ms3uOqbs5HktDqX8E9yxks5ruAyvgaJpZM4M0az1>
.
|
@zimbatm What's wrong with builtins.fetchTarball? Or something like let nixPath =
[
{ path = "https://github.com/NixOS/nixpkgs-channels/archive/nixos-unstable.tar.gz";
prefix = "nixpkgs";
}
]; in (import (builtins.findFile nixPath "nixpkgs") {}).hello |
A few thoughts:
|
Not a bad idea. I wonder the best way to do this.
If we have #9 and we're OK with putting a lot of stuff upstream into nix, that may be fine Alternatively, perhaps we can let users specify a list/directory of blessed plugins, rather than turning on all unsafe native eval? |
I agree with most of @edolstra's comments. |
@shlevy how is that channel loaded with nix-shell? Ideally I can run One option that hasn't been discussed yet would be to introduce pragmas to the language. That's what languages generally use to change behaviour that isn't configurable at runtime. For illustration's sake: default.nix ## build-use-sandbox=false
{ pkgs ? import <nixpkgs> {} }:
# ... The pragmas would only be loaded from the entry-point script. The user would have to be a trusted user for the pragmas to work. |
If we could get rid of the security features somehow then that would be much easier to implement. I think that all the security features revolve around the fact that a user could pollute the |
@zimbatm In my previous comment, which I redacted based on some feedback, I also mentioned an overlay solution (by which I was thinking of a unionfs-mount as well, overlayfs perhaps). Removing security from the discussion seems desirable. It could even be designed such that this overlay feature could then be disabled. |
Explain why the categorization was bad
Rendered: https://github.com/shlevy/rfcs/blob/per-project-config/rfcs/0011-per-project-config.md