I continue to dislike this pattern of putting bash inline in .nix files, especially here where it fully circumvents Shellcheck. Is there any way to check in this bash to the repo as a .sh file? Any way at all?

I agree with @ashoat here. Circumventing the ShellCheck CI is a problem since this diff will make it through 3 layers of CI (lint-staged, Buildkite, and GitHub Actions) without running a single ShellCheck pass over any of the code. That definitely can't be good.

To be fair, though, you explained that writeShellApplication runs ShellCheck on the code anyways. And I assume the checkPhase included in this diff is to also run ShellCheck. But it'd be nice if everyone could see the output of that ShellCheck run through something like Buildkite/Harbormaster logs, since it's accessible by all reviewers and is part of our CI.

Beyond this, reviewing a shell script (or really any code) stored as a string variable can be hard because it decreases readability. Is there no way to store the code in a separate file and import it into the .nix file?

I continue to dislike this pattern of putting bash inline in .nix files, especially here where it fully circumvents Shellcheck.

It's still running shellcheck as part of the package build on line 59, nix develop would fail if it wasn't compliant to shellcheck. I'll never be able to get completely rid of writing some bash, it's the glue which bridges the nix and environment worlds.

For longer scripts in the future, I should be able to write most of the logic in a separate script though.

Please provide a video or several screenshots showing what this prompt looks like in a variety of different contexts.

Rgr

What do you think of using Powerline? In my opinion it looks pretty cool...

This was easier to do than I thought, I'll just stick powerline in here

Beyond this, reviewing a shell script (or really any code) stored as a string variable can be hard because it decreases readability. Is there no way to store the code in a separate file and import it into the .nix file?

The main motivation to use bash embedded in nix is that I can interpolate nix paths directly into the scripts, and not have to worry about "handing off" a bunch of logic around where things are.

Would love a response to my question above:

Is there any way to check in this bash to the repo as a .sh file? Any way at all?

@jon, would love if you could rack your brain to come up with some potential ways to make this happen. Are you 1000% sure that there is absolutely no possible way to do this at all?

@jon, would love if you could rack your brain to come up with some potential ways to make this happen. Are you 1000% sure that there is absolutely no possible way to do this at all?

There is, I'll update this diff with one workflow. But it will essentially be nix doing a bunch of <pkg_root>=${pkg} and then calling a script which assumes that pkg_root is defined.

That sounds great.

Can you update your upstream branch so that the test plan works with the latest revision?

Yea, was getting the mac logged into phabricator so I could upload the screen shots

Also it seems your files are still "Restricted", because I can't see them even though they're in the summary.

In D4790#138445, @ashoat wrote:

To make the files visible to everybody, you'll need to "attach" them. @abosh has written some advice on how to do this before... @abosh, would you mind putting that info into a doc on Notion and then sharing it with @jon?

Done! Wasn't sure where to add it, so just put it under Unsorted in Dev Notes.

Ran ShellCheck manually on the Bash code that was still stored in a string variable (like in better-prompt.nix and dev-shell.nix), and they had errors...I really think all shell code should be put into a .sh file so that at least you can have lint-staged or Buildkite lint them before reviewers have to take a look at it. I know it involves extra work on your end but it's more modular, cleaner to read, easier to review, and passes through our CI.

@abosh I moved as much as I could into a separate .sh file. The remaining bash is largely just setting some variables when passing the logic onto the other file.

Haven't looked at anything else yet, but just put up the double quote errors that ShellCheck reported.

I think you're runnning it on the multiple line string which eventually gets turned into a shell script. The "built" shell script has the following contents:

[12:34:50] jon@jon-desktop /home/jon/comm/comm (jonringer/better-prompt)
$ nix build .#better-prompt
[12:35:02] jon@jon-desktop /home/jon/comm/comm (jonringer/better-prompt)
$ cat ./result/bin/better-prompt
#!/nix/store/qm2lv1gpbyn0rsfai40cbvj3h4gz69yc-bash-5.1-p16/bin/bash

PATH=/nix/store/2gfhqcjha69y0gpjryrxp0y55sn4jnx6-python3.10-powerline-2.8.2/bin:$PATH
powerline_fonts=/nix/store/g46c2x9wy5xbnwmr1x3rarp6hgnszb94-powerline-fonts-2018-11-11
powerline_root=/nix/store/2gfhqcjha69y0gpjryrxp0y55sn4jnx6-python3.10-powerline-2.8.2

source /nix/store/9bj8v4c0ji8hcrl97r28khms0m9669fa-start-powerline.sh

Which is why shellcheck is happy when ran as part of the "better-prompt" package build