RFC 1001: Explicit installation method in edgedb server install

[tailhook]

Proposal

1. Always require edgedb install --method=package or edgedb install --method=docker for installation in non-interactive mode
2. Without that, print something like this:

   No installation method chosen, add:
   * --method=package -- to install Ubuntu native package (recommended)
   * --method=docker -- to install into a Docker container
   * --method=tar.gz -- install generic self-contained package
   or run `edgedb server install --interactive` and follow instructions
   

   Or

   No installation method chosen, add:
   * --method=docker -- to install into a Docker container (recommended)
   * Note: no package available for Ubuntu eoan
   or run `edgedb server install --interactive` and follow instructions
   

   Or

   No installation method chosen, add:
   * --method=package -- to install Ubuntu native package (recommended)
   * Note: docker installation unavailable, permission denied for /var/lib/docker.sock
   or run `edgedb server install --interactive` and follow instructions
   

We can simplify parameters like

Motivation

If we choose "the best available method" automatically, we can have unexpected switch between method in certain situations:

1. User upgraded the desktop from LTS version to unsupported one (only docker and tar.gz becomes available)
2. We started support of distribution/version we haven't supported yet
3. User failed to set permissions for docker socket
4. User intentionally set permissions for docker socket for root, and forgot to use sudo when running edgedb server

Even if we don't consider edgedb server install be used in production, there still a point of confusion:

1. If it's written in some corporate docs on installation
2. If there is automation for installing users' workspaces

Docs and Tutorials

We're going to recommend `edgedb server install --interactive'

[1st1]

Can we default to --method package and if no native package is available we error out suggesting docker?

[elprans]

I also think that defaulting to --method=package is and requiring an explicit --method for other methods would be my preferred way to handle this.

[tailhook]

Okay. That's fine for linux if we don't fallback to docker or tarball implicitly, right?

For windows both docker or WSL(2) aren't good defaults, right?

For macos: for me it's unclear if we want .pkg or brew being default (an there are macports).

[1st1]

For windows both docker or WSL(2) aren't good defaults, right?

Yes, for Windows I would always make --method required.

For macos: for me it's unclear if we want .pkg or brew being default (an there are macports).

Definitely not brew. I don't even think we should wrap brew or macports with our tooling. We can make .pkg the default, since using Docker on macos isn't ideal either.

[elprans]

Yes, for Windows I would always make --method required.

There are no native packages for Windows, so erroring out with no native package, use --method=docker would be equivalent to making it required.

We can make .pkg the default

Definitely. .pkg is the most reliable way to install a complex app on macOS that relies on a bunch of system shlibs. brew is a moving target with no compatibility guarantees.

[1st1]

There are no native packages for Windows, so erroring out with no native package, use --method=docker would be equivalent to making it required.

Basically it looks like we want to make --method to default to native. I think we should be consistent with this so when we have a native Windows package (I want to believe) the tool works consistently across all platforms. Also docker requires the actual docker present on your machine, so I bet a lot of people will see some error message anyways. So I'm -0 on making Docker the default on Windows.

[elprans]

So I'm -0 on making Docker the default on Windows.

That's not what I meant. I meant that the default --package=native would always error on Windows currently anyway, so there's no need to special-case Windows by making --package a required option to begin with.

IOW, I agree with you.

[tailhook]

And another related question: if there is an already installed edgedb-server in non-default method, say docker, edgedb server should:

1. Install package anyway
2. Bail out and show that edgedb is installed in docker
3. Bail out and mention that you can explicitly choose --method=package

Same applies when method is applied explicitly. Should we allow a parallel install by default or have any kind of --force-method flag to make that intention explicit?

[elprans]

I think we should not allow parallel install of the same major version regardless of the installation method, so 2.

[tailhook]

I think we should not allow parallel install of the same major version regardless of the installation method, so 2.

So --method=package --major=1-alpha3 or --method=package --nightly or just --major=1-alpha3 may succeed if we had previously installed --major=1-alpha2 --docker ?

[elprans]

So --method=package --major=1-alpha3 or --method=package --nightly or just --major=1-alpha3 may succeed if we had previously installed --major=1-alpha2 --docker ?

Yes.

[tailhook]

Done.

[tailhook]

Or @elprans do you need to update RFC?

[elprans]

Or @elprans do you need to update RFC?

Please open an issue in the rfc repo with a reminder. Just one issue with pointers to relevant implementation discussions is OK. Thanks!

[tailhook]

Or @elprans do you need to update RFC?

Please open an issue in the rfc repo with a reminder. Just one issue with pointers to relevant implementation discussions is OK. Thanks!

This is the RFC repo :) So just reopening.