Should process-compose up [disabled-proc] start the process?

[smeijer]

I'm not sure if this is a bug, a feature request, or just misunderstood on my side, but let's assume I have a disabled process.

As intended, that process will not auto-start when running process-compose up. However, it will also not start when running process-compose up my-disabled-process. That last one is unexpected for me, as I now don't seem to have a (nice) way to run just that single process.

There is a workaround: run process-compose up my-disabled-process —-keep-tui, select the process, and start it using F7. But I guess there has to be a better way.

TDLR: Should process-compose up [disabled-proc] start the the process even if it's been disabled, or is there another way prevent processes from auto starting on process-compose up?

[F1bonacc1]

Hi @smeijer,

It is possible to make the disabled processes start if explicitly specified, but this creates a list of other unexpected scenarios:

1. process-compose up disabled_A, enabled_B - what if someone wants to start A only when needed?
2. process-compose up disabled_1, ..., disabled_N --keep-project - what if someone wants full control of the start order?

Possible solutions:

1. I can add a flag start_if_explicitly_specified_on_up or something in that sense.
2. Somewhat related to your other issue Add extends keyword to simplify overrides #270, use overrides that enable specific processes.
3. Use ENV variables to control the disabled value (true or false).
4. Use VARS to define conditions (if exist) to control the disabled values. This will require a minor development.
5. An interesting option will be to POC something similar to Helm overrides: process-compose up disabled_A --set processes.disabled_A.disabled=false

What do you think will work best for the majority of the users?

[smeijer]

Re the first unexpected case

process-compose up disabled_A, enabled_B - what if someone wants to start A only when needed?

I'd expect both A and B, and any process A and B depend on, to be started. If the user only wants to start A when it's needed, then it should be a dependency of B, and they should run process-compose up B. To my understanding, that's the behavior described in the docs

Synopsis
Run all the process compose processes. If one or more process names are passed as arguments, will start them and their dependencies only
process-compose up [PROCESS...] [flags]

What's the usecase of starting a process but not it's dependencies? Is that currently possible?

Same with start order. I would find it confusing if start order was determined by my flags to up instead of just based on the compose file. For me up [process] is just a way to start that process, and it's dependencies. Regardless of the disabled attribute.

Re solutions

1. Possible, and useful, though it'd mean we'd have to run it trough an alias for better UX. Not an issue for me, just something to consider. I mean, think process-compose up docs --start_if_explicitly_specified_on_up vs process-compose up docs or via an alternative task run-docs which would then invoke the former command.
2. I now see the overlap. That could help.
3. Same as 1
4. Same as 1, right?
5. Same as 1.

Don't get me wrong. I'm not against any of the suggestions, and don't mean to sound negative, because I'm not. I just don't see them as an option for the average user.

The usecase is that we have a process-compose.yml in the root of our project, and we have various services/processes. Some of them, like the nextjs app that runs our docs, don't need to run every day. We only need that service when working on the docs. So while an override would work, it feels cumbersome.

The intention of this ticket wasn't a future request. I think if you say that it works as designed, we can close this ticket, as the current overrides would then cover it.

Completely separate of the current up [disabled-process] topic, I do think adding 5 (Helm overrides) would be amazing. I image it being used to for example override env vars, or run one of the services with different config to test something just "this once". Use cases that can now already be achieved by temporarily adding an overrides file, but without creating the file.

[F1bonacc1]

I agree that from UX POV, for this specific use case, the best option would be to call process-compose up [ An explicit list of processes. All the processes will start, even if disabled ].
My only concern is that it might break someone else's use case workflow (see below).

I'd expect both A and B, and any process A and B depend on, to be started. If the user only wants to start A when it's needed, then it should be a dependency of B, and they should run process-compose up B.

Consider the following use case:

version: "0.5"
processes:
  disabled_A:
    command: "run long CPP compilation"
    disabled: true
  enabled_B:
    command: "run the compiled CPP process"

With TUI or CLI you can interact, debug B, and only trigger its recompilation when needed. Usually one would run B without A. But A is nice to have in TUI to trigger when needed.

What's the use case of starting a process but not its dependencies? Is that currently possible?

It's possible with the --no-deps flag.

Don't get me wrong. I'm not against any of the suggestions, and don't mean to sound negative, because I'm not. I just don't see them as an option for the average user.

Agreed, I should have added option 0 - running PC up with a list of process names would start them, even if disabled.
I am currently leaning toward this option.

[F1bonacc1]

Added in v1.40.0

[smeijer]

Sweet. Thanks!