No xdg-open command, so host Browser cannot be started

[nmemoto]

When starting a browser by executing cli on a terminal in devcontainer (VSCode Remote - Container), if the browser startup depends on xdg-open, it will fail because the xdg-open command does not exist.

For example, the following is obtained by executing cdktf init.

$ cdktf init --template="typescript"
Welcome to CDK for Terraform!

By default, cdktf allows you to manage the state of your stacks using Terraform Cloud for free.
cdktf will request an API token for app.terraform.io using your browser.

If login is successful, cdktf will store the token in plain text in
the following file for use by subsequent Terraform commands:
    /home/node/.terraform.d/credentials.tfrc.json

Note: The local storage mode isn't recommended for storing the state of your stacks.

? Do you want to continue with Terraform Cloud remote state management? Yes

opening webpage using your browser.....

If the web browser didn't open the window automatically, you can go to the following url:
        https://app.terraform.io/app/settings/tokens?source=terraform-login

? Token for app.terraform.io 🔑 [input is hidden] /usr/local/share/npm-global/lib/node_modules/cdktf-cli/node_modules/yoga-layout-prebuilt/yoga-layout/build/Release/nbind.js:53
        throw ex;
        ^

Error: spawn xdg-open ENOENT
    at Process.ChildProcess._handle.onexit (node:internal/child_process:283:19)
    at onErrorNT (node:internal/child_process:478:16)
    at processTicksAndRejections (node:internal/process/task_queues:83:21)
Emitted 'error' event on ChildProcess instance at:
    at Process.ChildProcess._handle.onexit (node:internal/child_process:289:12)
    at onErrorNT (node:internal/child_process:478:16)
    at processTicksAndRejections (node:internal/process/task_queues:83:21) {
  errno: -2,
  code: 'ENOENT',
  syscall: 'spawn xdg-open',
  path: 'xdg-open',
  spawnargs: [
    'https://app.terraform.io/app/settings/tokens?source=terraform-login'
  ]
}

CLI tools that use the environment variable BROWSER, such as github-cli, are not affected, but there must be many CLI tools that use xdg-open.

I originally submitted the form below, but I thought it was a devcontainer issue, so I submitted it here.

hashicorp/terraform-cdk#2132

[nmemoto]

#178 is my suggestion. Could you please confirm it?

[samruddhikhandale]

Hi @nmemoto,
I would like to understand the scenario for myself, could you provide me details on your dev container config?
what base image and Features does it has? or is it using some Remote Containers' definition ?

[nmemoto]

@samruddhikhandale Thanks for checking my pull request.

The source code I used is below.
https://github.com/nmemoto/try-cdktf

The settings for devcontainer are below.
devcontainer.json

{
    "name": "try-cdktf",
    "build": {
      "dockerfile": "Dockerfile",
      "cacheFrom": "ghcr.io/nmemoto/try-cdktf"
    },
    "customizations": {
      "vscode": {
          "extensions": [
              "GitHub.vscode-pull-request-github",
              "eamodio.gitlens"
          ]
      }
    },
    "features": {
      "ghcr.io/devcontainers/features/docker-from-docker:1": {
        "version": "latest"
      },
      "ghcr.io/devcontainers/features/terraform:1": {
          "version": "latest"
      },
      "ghcr.io/devcontainers/features/github-cli:1": {
        "version": "latest"
      },
    },
    "remoteUser": "node",
    "postCreateCommand": "npm install --global cdktf-cli@latest"
  }

Dockerfile

FROM mcr.microsoft.com/devcontainers/typescript-node:latest

[samruddhikhandale]

Thanks for the details. I agree that your proposal in #178 makes sense for your dev container configuration and will help solve the issue.

I am thinking from another perspective where the config doesn't use an image which depends on the common-utils Feature. In that case, I believe it would make more sense if we add xdg-utils to the terraform Feature (as the xdg-utils is needed by cdktf - a CDK for Terraform). What do you think?

[nmemoto]

@samruddhikhandale Your suggestion seemed like a solution for my current situation.

My concern was that many CLI tools provided by major cloud services, not just terraform, open the browser for its authentication. Many such CLI tools probably assume xdg-open. (For example, the standard Go package uses xdg-open at https://github.com/pkg/browser/blob/master/browser_linux.go#L9.)

From that point of view, I still thought the xdg-utils installation process needed to be handled in a way that was not limited to Terraform's features and was a change that should go into common-utils.

Recently, bamurtaugh pointed me to an issue of #67.
As this issue is being sorted out, I now believe that if features that use devcontainer in vscode remote containers are extracted, this change should go in that feature. (So I have closed #178).

What are your thoughts on this point?

[samruddhikhandale]

You have highlighted a very good point, I missed how widely used it could be.

I now believe that if features that use devcontainer in vscode remote containers are extracted, this change should go in that feature.

I am not sure if I have understood your point completely, but if we add xdg-utils to common-utils then it will get added to all the images published by https://github.com/devcontainers/images. So that seems like a good solution to me.

I am thinking from another perspective where the config doesn't use an image which depends on the common-utils Feature

In that case, they could use the common-utils Feature as well. Even with the proposal changes in #67 we would still have this Feature like a grab bag with all the utils and libraries.

[nmemoto]

@samruddhikhandale Would you approve changes to the pull request for #178 ?

If so, I will let this pull request be re-opened.

I would also like to apply this pull request at this time, assuming that the xdg-utils installation process is moved to the appropriate feature at the time common-utils is disassembled in the future.
(Due to the following concerns, I was going to make another pull request to have the change made to the appropriate feature after common-utils is broken up, since the scope of the impact of this change is significant.)

My concern is that xdg-utils is clearly an unnecessary package for the devcontainer use case with CI.
Also, not everyone necessarily uses such CLI tools.
I was a little unsure if this pull request change is a change that can provide benefits beyond the disadvantages of container bloat (about 220MB increase).

xdg-utils installation process log

node ➜ /workspaces/try-cdktf (main) $ sudo apt-get install xdg-utils
Reading package lists... Done
Building dependency tree       
Reading state information... Done
The following additional packages will be installed:
  dbus libapparmor1 libauthen-sasl-perl libdata-dump-perl libdbus-1-3 libdrm-amdgpu1 libdrm-common libdrm-intel1
  libdrm-nouveau2 libdrm-radeon1 libdrm2 libencode-locale-perl libfile-basedir-perl libfile-desktopentry-perl
  libfile-listing-perl libfile-mimeinfo-perl libfont-afm-perl libfontenc1 libgl1 libgl1-mesa-dri libglapi-mesa
  libglvnd0 libglx-mesa0 libglx0 libhtml-form-perl libhtml-format-perl libhtml-parser-perl libhtml-tagset-perl
  libhtml-tree-perl libhttp-cookies-perl libhttp-daemon-perl libhttp-date-perl libhttp-message-perl
  libhttp-negotiate-perl libio-html-perl libio-socket-ssl-perl libio-stringy-perl libipc-system-simple-perl libllvm7
  liblwp-mediatypes-perl liblwp-protocol-https-perl libmailtools-perl libnet-dbus-perl libnet-http-perl
  libnet-smtp-ssl-perl libnet-ssleay-perl libpciaccess0 libsensors-config libsensors5 libtext-iconv-perl
  libtie-ixhash-perl libtimedate-perl libtry-tiny-perl liburi-perl libwww-perl libwww-robotrules-perl
  libx11-protocol-perl libx11-xcb1 libxaw7 libxcb-dri2-0 libxcb-dri3-0 libxcb-glx0 libxcb-present0 libxcb-shape0
  libxcb-sync1 libxcomposite1 libxcursor1 libxdamage1 libxfixes3 libxft2 libxi6 libxinerama1 libxml-parser-perl
  libxml-twig-perl libxml-xpathengine-perl libxmu6 libxmuu1 libxpm4 libxrandr2 libxshmfence1 libxtst6 libxv1
  libxxf86dga1 libxxf86vm1 perl-openssl-defaults x11-utils x11-xserver-utils
Suggested packages:
  default-dbus-session-bus | dbus-session-bus libdigest-hmac-perl libgssapi-perl libcrypt-ssleay-perl pciutils
  lm-sensors libauthen-ntlm-perl libunicode-map8-perl libunicode-string-perl xml-twig-tools mesa-utils nickle
  cairo-5c xorg-docs-core
The following NEW packages will be installed:
  dbus libapparmor1 libauthen-sasl-perl libdata-dump-perl libdbus-1-3 libdrm-amdgpu1 libdrm-common libdrm-intel1
  libdrm-nouveau2 libdrm-radeon1 libdrm2 libencode-locale-perl libfile-basedir-perl libfile-desktopentry-perl
  libfile-listing-perl libfile-mimeinfo-perl libfont-afm-perl libfontenc1 libgl1 libgl1-mesa-dri libglapi-mesa
  libglvnd0 libglx-mesa0 libglx0 libhtml-form-perl libhtml-format-perl libhtml-parser-perl libhtml-tagset-perl
  libhtml-tree-perl libhttp-cookies-perl libhttp-daemon-perl libhttp-date-perl libhttp-message-perl
  libhttp-negotiate-perl libio-html-perl libio-socket-ssl-perl libio-stringy-perl libipc-system-simple-perl libllvm7
  liblwp-mediatypes-perl liblwp-protocol-https-perl libmailtools-perl libnet-dbus-perl libnet-http-perl
  libnet-smtp-ssl-perl libnet-ssleay-perl libpciaccess0 libsensors-config libsensors5 libtext-iconv-perl
  libtie-ixhash-perl libtimedate-perl libtry-tiny-perl liburi-perl libwww-perl libwww-robotrules-perl
  libx11-protocol-perl libx11-xcb1 libxaw7 libxcb-dri2-0 libxcb-dri3-0 libxcb-glx0 libxcb-present0 libxcb-shape0
  libxcb-sync1 libxcomposite1 libxcursor1 libxdamage1 libxfixes3 libxft2 libxi6 libxinerama1 libxml-parser-perl
  libxml-twig-perl libxml-xpathengine-perl libxmu6 libxmuu1 libxpm4 libxrandr2 libxshmfence1 libxtst6 libxv1
  libxxf86dga1 libxxf86vm1 perl-openssl-defaults x11-utils x11-xserver-utils xdg-utils
0 upgraded, 88 newly installed, 0 to remove and 37 not upgraded.
Need to get 25.7 MB of archives.
After this operation, 227 MB of additional disk space will be used.

[eitsupi]

My concern was that many CLI tools provided by major cloud services, not just terraform, open the browser for its authentication. Many such CLI tools probably assume xdg-open. (For example, the standard Go package uses xdg-open at pkg/browser@master/browser_linux.go#L9.)

From that point of view, I still thought the xdg-utils installation process needed to be handled in a way that was not limited to Terraform's features and was a change that should go into common-utils.

How are those tools installed?
Wouldn't it make more sense to install them in a devcontainer feature?

[nmemoto]

@eitsupi Thanks for caring about this issue.

Wouldn't it make more sense to install them in a devcontainer feature?

That may be so.

On the other hand, I believe there are lightweight CLI tools that are not so lightweight as to create devcontainer features.
For example, nmemoto/gh-trending, which I created, is a good example. This is a tool that checks GitHub Trending with TUI and moves to the web page of the selected repository.
Since it is a very small tool, I would not create a dedicated devcontainer feature for this tool.

[nmemoto]

Also, the assumption that even major cloud service CLI tools will be created with devcontainer features seems a bit too idealistic.