azure-cli: Could not start dynamically linked executable: /home/<user>/.azure/bin/bicep

hensou commented 9 months ago

Describe the bug

The azure-cli package includes a binary bicep that compiles and analyses .bicep files.

Steps To Reproduce

Steps to reproduce the behavior:

Install azure-cli
Login
Create this simple example.bicep file:
```
targetScope='subscription'
```

// Resource creation resource newResourceGroup 'Microsoft.Resources/resourceGroups@2023-07-01' = { name: 'test' location: 'germanywestcentral' properties: {} }

4. Try to deploy it with:
```console
az deployment sub create \
    --location germanywestcentral \
    --template-file example.bicep

Expected behavior

It should not fail.

Additional context

I get the following log:

➜  🫠 azure-iac-experiments git:(main) ✗ az deployment sub create --location germanywestcentral                           --template-file infra/resource-group/resource-group.bicep

Could not start dynamically linked executable: /home/hensou/.azure/bin/bicep
NixOS cannot run dynamically linked executables intended for generic
linux environments out of the box. For more information, see:
https://nix.dev/permalink/stub-ld

Notify maintainers

@AkechiShiro @jonringer

Metadata

Please run nix-shell -p nix-info --run "nix-info -m" and paste the result.

[user@system:~]$ nix-shell -p nix-info --run "nix-info -m"
 - system: `"x86_64-linux"`
 - host os: `Linux 6.6.10, NixOS, 24.05 (Uakari), 24.05pre567011.46ae0210ce16`
 - multi-user?: `yes`
 - sandbox: `yes`
 - version: `nix-env (Nix) 2.18.1`
 - channels(root): `"home-manager, nixos, nixos-hardware"`
 - nixpkgs: `/nix/var/nix/profiles/per-user/root/channels/nixos`

Add a :+1: reaction to issues you find important.

AkechiShiro commented 9 months ago

Hi @hensou How did you install bicep ?

It is possible to install it by running az bicep install and then install it under $HOME/.azure/bin or $AZURE_CONFIG_DIR (if defined in your shell configuration file) which is clearly out of the store. Hence it's very unlikely to work as mentioned here : https://nix.dev/permalink/stub-ld

This bug I'd say is due to two current issues which are more general that we have the CLI :

Some configuration file of azure-cli is outside the nix store and the CLI can download binaries in $HOME/.azure/bin or in $AZURE_CONFIG_DIR/bin if it is defined.
Work has started to convert the configuration file into something in the store but it's major change in the azure-cli package, see https://github.com/NixOS/nixpkgs/pull/276695 (introducing the AZURE_IMMUTABLE configuration file)

upstream code defines the config directory here and the bicep subcommand seems to use it here

A quick workaround if bicep was packaged in nixpkgs, would be to configure the CLI to always use Bicep from the PATH, setting it to bicep.use_binary_from_path=True (output of az bicep --help) :

az config set bicep.use_binary_from_path=True/False/if_found_in_ci
            Specify whether to use Bicep CLI from PATH or not. The default value is if_found_in_ci.

But that is not possible since bicep is not packaged in Nixpkgs.

hensou commented 9 months ago

Hi @AkechiShiro, thanks and sorry for my late reply. I don't remember installing bicep specifically, at first I thought it was installed together with the azure-cli, but since I also installed vscode and the azure bicep extensions there is a chance that vscode executed az bicep install.

It is interesting that from within vscode it does work properly, it just when I try to use it from the cli that provokes this error.

I guess for now the only option is to wait right?

AkechiShiro commented 9 months ago

Wait or contribute, until we can get to this issue (right now, the azure-cli fails to build in Master and tests are failing for version 2.56.0, we're focusing our efforts on fixing those issue first), see #281213 #281183

The vscode bicep must be statically built, if you can find the path to the file and run file on it or check the ldd output if it is not statically compiled.

AkechiShiro commented 9 months ago

@katexochen any input on this issue ?

katexochen commented 9 months ago

A quick workaround if bicep was packaged in nixpkgs, would be to configure the CLI to always use Bicep from the PATH, setting it to bicep.use_binary_from_path=True

I think packaging bicep and consuming it from PATH is likely the best solution. @hensou could you open a separate packaging request for bicep? I haven't package a dotnet app yet. https://github.com/Azure/bicep

hensou commented 9 months ago

@katexochen, done, I created the package request in https://github.com/NixOS/nixpkgs/issues/282826 .

Is there anything I can do to help on https://github.com/NixOS/nixpkgs/pull/281183?

katexochen commented 9 months ago

Thanks!

Is there anything I can do to help on https://github.com/NixOS/nixpkgs/pull/281183?

Sure! Tests currently fail, see https://github.com/NixOS/nixpkgs/pull/281183#issuecomment-1902070852 and we need to understand why.

khaneliman commented 7 months ago

Was creating the package in https://github.com/NixOS/nixpkgs/pull/285440 but didn't know how you wanted to join it to azure-cli. Is this something we can provide in path and it picks up or does it require a config setting in azure-cli to even bother looking for it?

EDIT: bicep was merged so the binary will be available in nixpkgs.

katexochen commented 4 weeks ago

So now that we have bicep packaged, should we add it to the azure-cli closure? Would add another 150+ MB. I'm not sure it's worth it. One the one hand I like if things work out of the box, but this doesn't seem something hit by many users (no thumbs up on this issue). Wdyt?

AkechiShiro commented 4 weeks ago

I think there should be a flag to override by default let's not include bicep in the closure

katexochen commented 4 weeks ago

So azure-cli-full it is.. :smiling_face_with_tear: Might be an opportunity to check for other things that might not be often required, current size is just awful.

NixOS / nixpkgs