[Feat]: I wonder if you can create a choice that we can chose config file in other path

[Eggwardhan]

What is your suggestion?

My Home path is no space left,So I try to read config from other places.

[houzhaohui@BJ-IDC1-10-10-17-36 code-server-4.0.1-linux-amd64]$ ./bin/code-server --config=./.config/config.yaml 
[2023-05-29T13:57:44.948Z] info  code-server 4.0.1 735c6da829535969ff7193c79379299e4a1cb9bc
[2023-05-29T13:57:44.950Z] info  Using user-data-dir ~/.local/share/code-server
[2023-05-29T13:57:44.953Z] error parent:54473 Uncaught exception: ENOSPC: no space left on device, write
[2023-05-29T13:57:44.954Z] error parent:54473 Error: ENOSPC: no space left on device, write
[2023-05-29T13:57:44.965Z] info  Using config file ./.config/config.yaml
[2023-05-29T13:57:44.965Z] info  HTTP server listening on http://10.10.17.36:8484/ 
[2023-05-29T13:57:44.966Z] info    - Authentication is enabled
[2023-05-29T13:57:44.966Z] info      - Using password from ./.config/config.yaml
[2023-05-29T13:57:44.966Z] info    - Not serving HTTPS 

Why do you want this feature?

start code server by defining other config path.

Are there any workarounds to get this functionality today?

No

Are you interested in submitting a PR for this?

No

[code-asher]

You can change the config file with --config, is that what you mean?

For example:

code-server --config=/tmp/config.yaml

The data directory can also be changed:

code-server --user-data-dir /tmp/code-server-data

[mirekphd]

--config

Yes, so say your docs (at least for --user-data-dir), but neither of these two options seems to be available in code-server binary:

(base) coder@5800d4264eeb:/home/jovyan$ code-server --version
1.79.2
695af097c7bd098fbf017ce3ac85e09bbc5dda06
x64

(base) coder@5800d4264eeb:/home/jovyan$ code-server --user-data-dir
Ignoring option 'user-data-dir': not supported for code-server.

(base) coder@5800d4264eeb:/home/jovyan$ code-server --config
Ignoring option 'config': not supported for code-server.

[mirekphd]

neither of these two options seems to be available in code-server binary:

Turns out there are two instances of code-server available at runtime, and the one which is executed by default (without specifying its path) is the "wrong one" (/usr/lib/../remote-cli/code-server). The "right one" does have both --user-data-dir and --config options available.

More info:

# have been using the wrong one:
(base) coder@5800d4264eeb:/home/jovyan$ which code-server
/usr/lib/code-server/lib/vscode/bin/remote-cli/code-server

(base) coder@5800d4264eeb:/home/jovyan$ /usr/lib/code-server/lib/vscode/bin/remote-cli/code-server --config
Ignoring option 'config': not supported for code-server.

(base) coder@5800d4264eeb:/home/jovyan$ /usr/lib/code-server/lib/vscode/bin/remote-cli/code-server --user-data-dir
Ignoring option 'user-data-dir': not supported for code-server.

#
#
# ... but finally realized there is another code-server in the container (still a mystery to me why),
# so I switched to the "right one" (the one I actually directly installed in the Dockerfile):
(base) coder@5800d4264eeb:/home/jovyan$ /usr/bin/code-server --user-data-dir
[2023-06-26T11:47:53.539Z] error --user-data-dir requires a value

(base) coder@5800d4264eeb:/home/jovyan$ /usr/bin/code-server --config
[2023-06-26T11:48:06.579Z] error --config requires a value

Probably aliasing the correct code-server version could prevent such cases (ping to the docs authors).

[code-asher]

Yup this is the expected (but confusing) behavior.

VS Code provides their own code-server binary when inside the integrated terminal.

It is a separate binary meant only to interact with the current session of code-server without the ability to spin up a new one.

Personally I would rather see it be the same binary but we try not to deviate from upstream. I can only guess as to their intent but perhaps they consider launching a new server while already inside VS Code to be an invalid use case.

Documenting this difference seems like a good idea to me. Maybe a patch to the remote-cli binary to mention that it is a different binary when the options are invalid could also be useful.

[code-asher]

Maybe it would be good to override this with our binary though to provide a consistent experience. Before that though we would want to implement the remaining features missing from ours that are present in VS Code's (--wait for example).

[code-asher]

I think we ended up leaving the other binary so as to have parity with Codespaces.