Avoid looking at PS1 to determine user's preference,
and just explicity ask them.
Use a file to save the preference between invocations (e.g. nix develop)
Differential D4843
[Nix] Use file to determine user preference • jon on Aug 15 2022, 6:49 PM. Authored by Tags None Referenced Files
Details
Avoid looking at PS1 to determine user's preference, Use a file to save the preference between invocations (e.g. nix develop) nix develop # should get prompted # if yes, prompt should change # if no, prompt should not change rm ~/Library/Caches/app.comm/enable-powerline exit nix develop # try other option
Diff Detail
Event Timeline
Comment Actions Going to review this more carefully after weekly sync, but just wanted to make sure these changes are solely cosmetic? Doesn't it make the nix environment a little less "deterministic" in that it introduces potential variability for different members of the team? Not sure it makes a practical difference but just wondering. Comment Actions Nix is about reproducable builds, not about forcing every dev to have the exact same settings for their shell Comment Actions Couldn't different shell settings potentially break reproducibility? Like if one dev sets a shell option eg shopt -s globstar that would definitely change behavior of build scripts and break reproducibility. These changes definitely seem "benign" and cosmetic and I'm not arguing against them, just figured we'd generally want to limit the amount of variability in environment. Comment Actions
This is true, but even if we didn't include the option to use Powerline it would still be true. Even if we're all on Nix, we can't prevent someone from changing their settings. Developers will inevitably have different shell settings or use different shells altogether. I myself use fish which is different from zsh and bash, but it's my responsibility to understand the differences and take into account that variability. Your point is still valid. The globstar example is a good one because using ** in scripts is really common because it's so useful. Yet it can only be run if the globstar option is set. Thus in the future, we may run into issues with different shell configurations, but this script's purpose is just to change the prompt / colors a user sees. It shouldn't modify something that could break reproducibility. @jon I'm curious for your input.
Comment Actions
Nix has strong guarantees around building packages with it. Shell usage is a non-goal for nix.
We've already had this with zsh's extGlob syntax and that things like nix run .#mariadb-up, the solution is to escape it nix run '.#mariadb-up'.
Not in a meaningful way, the shebangs will force the scripts to be executed by a particular shell. Currently we force bash on almost all of our scripts anyway.
Yea, but I would argue there's a difference between how a developer interfaces with tooling, and what tooling is present. The main purpose of leveraging nix is so that everyone has the same tooling, but I think it's best for developers to choose their own way to interface with it. For example, I already have a pretty extensive bash setup, and would like to have it over powerline in my setups.
Comment Actions
You're able to use fish in a nix environment? Comment Actions
You would have to manually launch it after nix develop but you can. fish will inherit all of the relevant ENV vars needed. Comment Actions Does this stack fix the issue I was seeing where press-up-to-see-previous-commands wasn't working? Comment Actions
I think that's a separate issue, as my terminal has the normal "up means go up in history" behavior. In https://linear.app/comm/issue/ENG-1550#comment-854f3150 I mention that it's possible that your terminal is somehow put in "alternate console" mode. The fix for which is usually doing tput rmcup. I could forcefully run this in nix develop as this will likely have the desired behavior anyway, but might cause issues with things like tmux (haven't tried).
Pretty much any application which grabs the cursor will do this: less, more, vim, nano, etc. If the program doesn't exit cleanly then your console can be in this weird state of not being "released" back to the parent process correctly. If you're only getting this when doing nix develop, then that's very odd. My m1, intel mac and NixOS aren't having that behavior even when using Powerline. We can create another task, and I can try to troubleshoot it separately. |