devenv up fails with error

[MatzHilven]

Describe the bug
When I try executing devenv up I get the following error.
It should start a postgres and redis process.

To reproduce
https://gist.github.com/MatzHilven/4201608fc91df95d2a852e3c6d386bb7

• Building processes ...
• Using Cachix: devenv
✔ Building processes in 1.2s.
• Starting processes ...• Building shell ...
✔ Building shell in 1.0s.
✨ devenv 1.0.2 is out of date. Please update to 1.0.3: https://devenv.sh/getting-started/#installation
panic: exec: "infocmp": executable file not found in $PATH

goroutine 13 [running]:
github.com/f1bonacc1/process-compose/src/tui.SetupTui({0xe5d8f0?, 0xc000662320?}, {0xc0000a1f80, 0x2, 0x0?})
        github.com/f1bonacc1/process-compose/src/tui/view.go:482 +0x156
github.com/f1bonacc1/process-compose/src/cmd.startTui({0xe5d8f0, 0xc000662320})
        github.com/f1bonacc1/process-compose/src/cmd/project_runner.go:92 +0x179
created by github.com/f1bonacc1/process-compose/src/cmd.runTui in goroutine 1
        github.com/f1bonacc1/process-compose/src/cmd/project_runner.go:76 +0x65

Version
devenv 1.0.2 (x86_64-linux)

[domenkozar]

Does it help if you add pkgs.ncurses to `packages?

[MatzHilven]

Does it help if you add pkgs.ncurses to `packages?

Getting the same error

  packages = [
    pkgs.openssl
    pkgs.libyaml
    pkgs.ncurses
];

[MatzHilven]

I installed ncurses globally and it's now returning the following error:

panic: exit status 1

goroutine 37 [running]:
github.com/f1bonacc1/process-compose/src/tui.SetupTui({0xe5d8f0?, 0xc0004055e0?}, {0xc00026ff80, 0x2, 0x0?})
        github.com/f1bonacc1/process-compose/src/tui/view.go:482 +0x156
github.com/f1bonacc1/process-compose/src/cmd.startTui({0xe5d8f0, 0xc0004055e0})
        github.com/f1bonacc1/process-compose/src/cmd/project_runner.go:92 +0x179
created by github.com/f1bonacc1/process-compose/src/cmd.runTui in goroutine 1
        github.com/f1bonacc1/process-compose/src/cmd/project_runner.go:76 +0x65

[domenkozar]

can you paste devenv info

[MatzHilven]

`❯ devenv info

env

• ADVISORY_LOCK: false
• BUNDLE_PATH: /home/matz/Documents/Coding/Ruby/Backend-devenv/.devenv/state/.bundle
• DEVENV_DOTFILE: /home/matz/Documents/Coding/Ruby/Backend-devenv/.devenv
• DEVENV_PROFILE: /nix/store/985rwc0igk9gqlc19wng8annywahvyfb-devenv-profile
• DEVENV_ROOT: /home/matz/Documents/Coding/Ruby/Backend-devenv
• DEVENV_RUNTIME: /tmp/devenv-1721d98
• DEVENV_STATE: /home/matz/Documents/Coding/Ruby/Backend-devenv/.devenv/state
• GEM_HOME: /home/matz/Documents/Coding/Ruby/Backend-devenv/.devenv/state/.bundle/ruby/3.3.0
• PGDATA: /home/matz/Documents/Coding/Ruby/Backend-devenv/.devenv/state/postgres
• PGHOST: /tmp/devenv-1721d98/postgres
• PGPORT: 5432
• PREPARED_STATEMENTS: false
• REDISDATA: /home/matz/Documents/Coding/Ruby/Backend-devenv/.devenv/state/redis
• REDIS_URL: redis://127.0.0.1:6379

packages

• process-compose-0.88.0
• redis-7.2.4
• postgresql-15.6
• start-postgres
• bundler-2.5.6
• ruby-3.3.0
• stdenv-linux
• gnumake-4.4.1
• clang-wrapper-17.0.6
• ccls-0.20230717
• gcc-wrapper-13.2.0
• pkg-config-wrapper-0.29.2
• openssl-3.0.13
• libyaml-0.2.5
• pkg-config-wrapper-0.29.2

processes

• postgres: exec /nix/store/ayqjps0b2abvvz5v293fi3i8baqf0wmy-postgres
• redis: exec /nix/store/rzxalzqsgjs65k1qxqhbs4qyy1w2vqjy-redis
  `

[F1bonacc1]

Please try to define TERM:
export TERM=xterm-256color
And run again.

[MatzHilven]

Please try to define TERM: export TERM=xterm-256color And run again.

Same error, tried exporting & setting via devenv ( env.TERM="xterm-256color";)

[autolyticus]

Hi, I've been having the same issue. It used to work fine with the older v0.6.3 version of devenv.

I believe this is something to do with the generation of the config file and a regression with the new detach option. Before devenv up in a non-interactive context would work fine, but seems like either that or the automatic detection of the tty is causing issues.

[domenkozar]

I've seen this in our tests as well, if we nail it down I'm happy to fix it!

[sandydoo]

@MatzHilven, I noticed you have clean: enabled: true in your devenv.yaml. Does the issue persist if you disable that? Or if you set clean: keep: [ "PATH", "TERM"]?

@autolisis, do happen to use the clean option in your devenv.yaml by any chance?

[autolyticus]

@sandydoo Nope, I've never had that key set.

Also, I do not seem to be facing this issue anymore since the v1.0.4 release, I do believe there was some modification to the process compose argument handling. I did have to set the following keys to get it to work. Not setting the unix-socket causes an error too (which maybe should be another issue)

  env.PC_DISABLE_TUI = "1";
  env.PC_TUI_ENABLED = "0";
  process.process-compose.tui = false;
  process.process-compose.unix-socket = "/tmp/process-compose.sock";
  process.process-compose.port = 9999;

Admittedly, this is a bit of a shotgun approach :) but I've not yet had the time to minimize this

[MatzHilven]

@MatzHilven, I noticed you have clean: enabled: true in your devenv.yaml. Does the issue persist if you disable that? Or if you set clean: keep: [ "PATH", "TERM"]?

@autolisis, do happen to use the clean option in your devenv.yaml by any chance?

It seems like the clean option was te culprit for me! After removing it, my postgres & redis server work fine

[sandydoo]

It seems like the clean option was te culprit for me! After removing it, my postgres & redis server work fine

Awesome!

I did have to set the following keys to get it to work. Not setting the unix-socket causes an error too (which maybe should be another issue)

Oh, so you disabled the TUI entirely. Hmm.
Regarding the unix-socket issue, I'll get that fixed. The way it's currently set up means that setting any one option removes all other defaults.

I've seen this in our tests as well, if we nail it down I'm happy to fix it!

@domenkozar, is this still an issue in the tests? Could you point me in the right direction?

[domenkozar]

I went through the latest tests and it seems like it's not happening anymore.

[sandydoo]

We'll need to modify the docs to explain the why the clean option is probably not what you want. It currently removes all env variables, which is an easy way bork the shell. Ideally it would be smart about the vars it removes, but this is tricky to get right.