-
-
Notifications
You must be signed in to change notification settings - Fork 159
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 0032] Phase running changes for better nix-shell use #32
Conversation
This comment has been minimized.
This comment has been minimized.
Good UX is important in everything. Anything that is clumsy will be fumbled with, and possibly be hated by the end-user, that's not a Nix-specific statement! Don't sell the desire for improvement short. Is there anything preventing your As for the RFC itself, other than the generic baseline deprecation concerns, the idea seems sound enough. In reality the "new way" isn't that much of a hassle compared to the status quo. This mostly affects the implementation for a default phase; the user overriding a phase won't need to bother, right?. As a new~ish user and developer running hooks also makes more sense than clobbering the |
No, it could be added straight away. But I am kind of hopeful it won't be needed.
Correct. You can see the changes needed in this commit: dezgeg/nixpkgs@87959f3 |
Good idea! I was annoyed by this multiple times and the downsides to his seem tiny. As more future work (out of scope of this RFC, which is good as-is):
Out of all of those 1.i. should be pretty easy to implement and a great help already. |
I actually experimented with implementing such tool at some point: https://github.com/dezgeg/nix-debug-shell but I am not particularly good with things like documentation or finishing stuff that I've started, so it's in a kind of forgotten state and potentially bitrotted by now. Maybe it could be moved to https://github.com/nix-community/ if there are people willing to work on it. |
Nice proposal. I definitely want this. https://github.com/ryantrinkle/nix-build-inplace is another such debug build helper. |
For Python (
I'm glad to see this is covered. This RFC looks good to me, though I think the Summary can be improved. Running the hooks independent of the phases has nothing to do with the UX of |
@FRidh do you have a pointer on where is there is such code in Python infra that need changes? I have found (and fixed) some such cases in my branch but none in Python.
Yeah, the hook changes are an afterthought that came up after I started writing the description... I will reword it a bit. |
This is probably off topic, but I'd like if we made the |
@dezgeg Actually, reading it again it is a bit different. |
Yep, it's a different case. The sort of Nix-level code in |
@dezgeg do you have a branch with this change? I would like to try it out, especially because of NixOS/nixpkgs@9333c1b |
The branch is mentioned under related-issues: https://github.com/dezgeg/nixpkgs/tree/better-run-phases |
Since there is nobody to decide and there hasn't been any opposition, should we merge this? |
It seems like a good target for 19.03. How much pain will it create for out-of-tree nix code? |
I usually use |
@dezgeg Are you ready for us to open nominations for a shepherd team as per the new RFC process? |
Closing for now. Feel free to reopen when this is ready for general review and shepherding. |
@lheckemann Do you still plan to make a meeting for this? |
For example, for building the Nix flake, you would do: $ nix develop --configure $ nix develop --install $ nix develop --installcheck
This pull request has been mentioned on NixOS Discourse. There might be relevant details there: https://discourse.nixos.org/t/nixpkgs-phases-which-shell-language-how-to-overwrite-phases/9307/3 |
This pull request has been mentioned on NixOS Discourse. There might be relevant details there: https://discourse.nixos.org/t/how-to-create-package-with-multiple-sources/9308/3 |
So, I've finally arranged the meeting with @Ericson2314 and @samueldr. Results:
|
This pull request has been mentioned on NixOS Discourse. There might be relevant details there: https://discourse.nixos.org/t/rfc32-phase-running-changes-for-better-nix-shell-use-fcp/9918/1 |
-buildPhase() { | ||
+defaultBuildPhase() { | ||
- runHook preBuild | ||
- | ||
# set to empty if unset | ||
: ${makeFlags=} | ||
|
||
@@ -1008,14 +1104,14 @@ buildPhase() { | ||
make ${makefile:+-f $makefile} "${flagsArray[@]}" | ||
unset flagsArray | ||
fi | ||
- | ||
- runHook postBuild | ||
} | ||
+ | ||
+buildPhase() { | ||
+ runHook preBuild | ||
+ | ||
+ if [ -n "$buildPhase" ]; then | ||
+ eval "$buildPhase" | ||
+ else | ||
+ defaultBuildPhase | ||
+ fi | ||
+ | ||
+ runHook postBuild | ||
+} | ||
|
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.
Has this not been implemented yet, or implemented differently?
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.
Haven't seen @dezgeg in a while, don't think this ever got implemented.
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.
Fwiw, NixOS/nixpkgs#175605 suggests a perhaps less breaking solution that's opt-in. Opting in is in itself messy though, so that's a reason to prefer this RFC if feasible.
…uments Some default.nix arguments
Co-authored-by: Linus Heckemann <git@sphalerite.org>
Making some minor tweaks to how phases are run in the stdenv to improve the UX of nix-shell.
Rendered view: https://github.com/dezgeg/rfcs/blob/phase-changes/rfcs/0032-run-phase-changes-for-better-nix-shell-use.md