aliases with env vars preceding their definition aren't parsed correctly

[kasimeka]

this issue builds onto #117 where parsing fails for aliases with = chars in them. after applying the patch shown in that issue, aliases that have = anywhere except the first word are parsed correctly, but if env vars are being set for the alias's command(s) the env var definition is picked up as the command instead leading to unexpected failures in resolution.

i wrote a repro of the issue at https://github.com/janw4ld/resholve-alias-env-vars-repro which uses the patch from #117 to parse alias ssh_prod='cd $(AWS_REGION=us-east-1 echo $PWD)' correctly, then error out on alias ls_use1='AWS_REGION=us-east-1 ls'

to run it:

$ nix run github:janw4ld/resholve-alias-env-vars-repro
error: builder for '/nix/store/69fdc3gmqk0skji2pvv61hmsqc3xfawy-ls-us-east-1-0.1.0.drv' failed with exit code 3;
       last 16 log lines:
       > Running phase: unpackPhase
       > unpacking source archive /nix/store/d9wfgplcixl4z277gbpyr1pgy1c3dy80-ls-us-east-1-unresholved-0.1.0
       > source root is ls-us-east-1-unresholved-0.1.0
       > Running phase: patchPhase
       > Running phase: updateAutotoolsGnuConfigScriptsPhase
       > Running phase: installPhase
       > Running phase: fixupPhase
       > [resholve context] : invoking resholve with PWD=/nix/store/l0zacr1n30jclfj3b66sm9m469f2djf9-ls-us-east-1-0.1.0
       > [resholve context] RESHOLVE_LORE=/nix/store/075jskrlr77rvh2952zfpxxy5kghjvx8-more-binlore
       > [resholve context] RESHOLVE_FIX=aliases
       > [resholve context] RESHOLVE_INPUTS=
       > [resholve context] RESHOLVE_INTERPRETER=/nix/store/k56w4s2vav93hir7lsfw0qkqd97qvqkr-bash-interactive-5.2p32/bin/bash
       > [resholve context] /nix/store/h63slfwa931hcb66h8xgcpk9cp161h9g-resholve-0.10.5/bin/resholve --overwrite bin/ls-us-east-1
       >   alias ls_use1='AWS_REGION=us-east-1 ls'
       >         ^~~~~~~~
       > /nix/store/l0zacr1n30jclfj3b66sm9m469f2djf9-ls-us-east-1-0.1.0/bin/ls-us-east-1:9: Couldn't resolve command 'AWS_REGION=us-east-1'
       For full logs, run 'nix-store -l /nix/store/69fdc3gmqk0skji2pvv61hmsqc3xfawy-ls-us-east-1-0.1.0.drv'.

[abathur]

Thanks for the report and repro.

The ~problem here is that I cheated and tried to see if we could bite these off even though they are inside single-quoted strings (the underlying OSH parser isn't giving us a structured representation of what's in them).

I think the "right" fix here (probably for both issues) is likely to be for resholve to go ahead and try to run the string for quoted alias definitions back through OSH's parser by themselves so that we're able to lean on its understanding of the string's contents.

I'll try to find time this week to look into implementing something.

---

For context, part of the reason to see if we could get away with ~cheating here is that I'm trying to avoid leaning any harder on being able to directly drive internal parts of the OSH parser than absolutely necessary until resholve is migrated off of Python2. (Some paths through that transition may leave resholve without the ability to readily leverage those parser internals. Until we know one way or the other, I'm trying to minimize how many corners I paint us into...)

[abathur]

Just updating since this is taking longer than I hoped.

I found a couple weekends in November to pull together a working implementation of this concept, but I realized while trying to nail down behavior with better test cases that there's a ~bug lurking in that approach that probably has a very small chance (in theory, at least) of causing some tricky-to-debug problems.

I haven't had much more time to work on it since, so I've just been stewing on it. At first I was tempted to report back that this might just need to wait until after the next time I update the OSH parser, since that'll already entail a refactor that will touch on some of the key details here.

But, I did eventually think of an approach that might work out well enough without waiting--I just haven't had much time to get into it.