Is this bash? How would I know that it's bash? Where does Nix show that it's executing this as bash?

Yes, it's bash. We can render the file, then check it

Can we put this inside a separate .sh file with a bash shebang? I

Not really, as nix needs to interpolate the paths of packages

If there's no way to separate this into its own .sh (probably unlikely), can you confirm that you've manually run ShellCheck against this code?

Looking through some of the other "trivial builders", there's also a writeShellApplication which checks the content with shellcheck

because I was having a lot of issues why it was crashing on mariadb_count=$(ps aux | grep -v grep | grep -c mariadbd) thought it was somethign to do with the [[ ]] because I was desperate.

Turns out grep normally fails if it finds 0 results. and forgot to undo this.

Does this line lock every dev's MariaDB version to 10.8?

It locks every reference to mariadb. Since I will only be referencing mariadb, then it should be every dev's env.

Should we lock to a specific patch version as well?

No, generally patch versions have good fixes. We want those when we update nixpkgs. AFAIK, mariadb only does maintenance and security backports to minor versions.

Should all of the tools we use be locked to a specific version like this?

Depends on the tool, I do something similar for protobuf. But most packages don't update in meaningful ways too often. Once we get some nix CI, we should be able to determine any regressions when updating nixpkgs, and react accordingly.

We can render the file, then check it

I have no idea what this means. I fear we're slipping into a pattern again where I ask a question and get a really short sentence in response. Please make sure to respond to each request with enough detail that we don't end up churning during diff review. If you leave out the detail in your first response, you are only causing more work for everybody – your reviewers and you.

To be absolutely clear, I am requesting that you should me the line of code that shows that this shell script is being executed as bash. Can you please link that line of code?

Not really, as nix needs to interpolate the paths of packages

Can those things be provided as inputs into the bash script?

Looking through some of the other "trivial builders", there's also a writeShellApplication which checks the content with shellcheck

At runtime? That doesn't sound ideal...

No, generally patch versions have good fixes. We want those when we update nixpkgs. AFAIK, mariadb only does maintenance and security backports to minor versions.

I don't disagree, but doesn't this compromise Nix's promise of reproducable builds? It sounds like different devs will have different versions.

I agree that patch versions have good fixes, but I would prefer a model where patch versions get pushed to each developer's environment when they are introduced. Instead, it appears that developers with the old version will not get the patched version... only people newly setting up the environment will get the patch versions. Or am I wrong?

(Ideally I wouldn't have to ask for further clarification here... you can reduce churn by interpreting what I am trying to ask, and giving a full response that covers everything.)

Should the last line of this command end with a backslash? Not sure if this will execute. But it is the only command in the script, so I don't know.

Going off of StackOverflow and StackExchange.

Assuming this doesn't need to be double quoted since the entire script is in quotes already? Same assumption for lines 74, 100, 104, 107, 122, and 124?

Yep, I had stdout and stderr on separate lines before, thanks

Correct, nix store paths are computed and can't have spaces in them

$ nix eval nixpkgs#hello.outPath
"/nix/store/j943c0z8m4qhx1vr3zzh91fjz1bnhg1h-hello-2.12.1"

I fear we're slipping into a pattern again where I ask a question and get a really short sentence in response. Please make sure to respond to each request with enough detail that we don't end up churning during diff review.

I expanded on this in a separate comment: https://phab.comm.dev/D4750#136994

But it probably should be part of the original response

It inherits the shell from the stdenv environment, which is going to contain bash v5.1

I am requesting that you should me the line of code that shows that this shell script is being executed as bash. Can you please link that line of code?

$ nix build github:commE2E/comm?ref=jonringer/mariadb#mariadb-up && head -n1 ./result/bin/mariadb-up
#!/nix/store/qm2lv1gpbyn0rsfai40cbvj3h4gz69yc-bash-5.1-p16/bin/bash

At runtime? That doesn't sound ideal...

It's a build time. In another comment, I linked to the nixpkgs definition of writeShellApplication which shows that it create a package where the contents of script are ran against shellcheck as part of the checkPhase (which is usually used for test suites).

In other words, writeShellApplication takes the scripts, runs it through a few tests (one of which is shellcheck), then re-exposes if it passed. If it failed any test then you would see any nix command trying to make use of it fail.

Can those things be provided as inputs into the bash script?

Possible, but that's unusual. Are we trying to solve shellcheck or trying to solve script re-use? If we're trying to solve shellcheck, then writeShellApplication already does this for us, so that's not much of a win. If we wanted to make the scripts more portable, then I think refactoring the script to just use PATH, and expose a nix wrapper script which sets the correct PATH then calls the portable script would make sense. However, I don't think we want to go down the path of supporting many different development environments.

but doesn't this compromise Nix's promise of reproducable builds?

Not really, reproducible just means starting from a known location A can you always get to same exact location B? If the anwser is yes, then it's reproducible. For nix, only updating the nix lock file or the overlay should really be affecting which packages get introduced into the environment. If programmer A has the same flake.lock and nix/overlay.nix as programmer B, then both programmers will have the exact same (usually byte-for-byte same) packages.

I think you are more concerned about mariadb_108 moving between developers. But mariadb_108 is determined by nixpkgs, which is frozen to a particular commit in the flake.lock file.

One of my youtube videos on flakes might help with understanding how this works a bit (although I do make the assumption that you've dabbled with nix) https://youtu.be/90P-Ml1318U?t=90

It sounds like different devs will have different versions.

If they have the same flake.lock and nix/overlay.nix then no, the packages should be exactly the same. But if we do need to update the package, then we can make the change in either the flake.lock (if nixpkgs has what we want) or the overlay(if nixpkgs doesn't have what we want); then ask "please rebase on the latest master and run nix develop again".

I agree that patch versions have good fixes, but I would prefer a model where patch versions get pushed to each developer's environment when they are introduced.

The patch version will likely be decided by the flake.lock which contains a reference to a specific checkout of nixpkgs. I'm most refering to when we do update the lock file, it will likely bump the patch version.

Instead, it appears that developers with the old version will not get the patched version... only people newly setting up the environment will get the patch versions. Or am I wrong?

For the purpose of the mariadb package which nix will reference, that is determined by the nixpkgs reference in the flake.lock and anything we might do in the overlay. As we only update the flake.lock every few months, it's more likely that individual users will have the exact same version.

wc -l counts the number of lines returned.
However, wc -l on mac will returns something like 0, so we feed it to xargs echo which will collapse whitespace to just a space between non-whitespace strings.

Not sure if it's better, but we could also use something like awk, like piping it to awk {print $1}?

I'm fine with this solution as well, but I find that less people know about awk than wc + xargs

yes

no, but shellcheck complains

I'll just take 93

Depends on the query optimizer. For MariaDB I would assume that it would know that the tuple info gets discarded, but COUNT(1) is a bit more explicit that the information of the user table is irrelevant.

Quoted them just for good measure

I did -Bse "<command>" to be consistent with the previous invocation