search

edgedb / edgedb-cli

The EdgeDB CLI
https://www.edgedb.com/docs/cli/index
Apache License 2.0
166 stars 23 forks source link

WSL does not have systemd #647

Closed Immortalin closed 2 years ago

Immortalin commented 2 years ago

Steps to Reproduce:

  1. edgedb project init
  2. Successfully installed 1.0-rc.4+c21decd
Initializing EdgeDB instance...
[systemctl] Created symlink /home/lin/.config/systemd/user/default.target.wants/edgedb-server@example.service → /home/lin/.config/systemd/user/edgedb-server@example.service.
[systemctl] Failed to connect to bus: No such file or directory
Applying migrations...
Everything is up to date. Revision initial
Bootstrapping complete, but there was an error creating the service: systemctl failed: exit status: 1 (command-line: "systemctl" "--user" "start" "edgedb-server@example.service")
You can start it manually via:
edgedb instance start example
elprans commented 2 years ago

This is a known issue. There are two workarounds currently:

  1. Use the Windows binary of the edgedb CLI. It is explicitly aware of WSL and uses WSL to run EdgeDB properly.
  2. Start instances manually as suggested: edgedb instance start example
Immortalin commented 2 years ago

Are there any performance implications when using the Windows binary? Will the DB be created on the WSL filesystem or will it be created on the Windows side?

elprans commented 2 years ago

Are there any performance implications when using the Windows binary?

None.

Will the DB be created on the WSL filesystem or will it be created on the Windows side?

The instances will be created in a new WSL distribution called EdgeDB.WSL.1. The only limitation of this approach is that you'll only be able to access EdgeDB instances from the Windows host, and not other WSL distros (this is a general WSL limitation, there's no cross-distro networking per se).

Immortalin commented 2 years ago

So if I am developing my app in WSL I should stick with the second method?

elprans commented 2 years ago

Yes.

The general rule is:

  1. For apps developed in Windows natively use the Windows edgedb binary.
  2. For apps developed in WSL, use the Linux edgedb binary (and use manual instance control for now)
elprans commented 2 years ago

@tailhook, is there anything we can do here to improve the experience?

tailhook commented 2 years ago

@tailhook, is there anything we can do here to improve the experience?

I'm not sure. The message is quite clear and doesn't suggest this is a bug by itself. I don't think it's a good idea to suggest running windows-native edgedb CLI because this is usually not what users want. We also can't check for WSL explicitly instead of checking for system, as I believe it should be technically possible to run systemd in WSL (although, you will have to log in to get the service running). Adding windows startup files from inside the user-managed WSL distribution may also lead to some undesired effects.

But generally I'm open to ideas.

Immortalin commented 2 years ago

There are three potential solutions: add the DB start service to the WSL user shell startup/profile script, add a GUI on the Windows side like what docker desktop does, or automatically start the instance behind the scenes when edgedb is ran in a project folder containing the toml file.

tailhook commented 2 years ago

There are three potential solutions: add the DB start service to the WSL user shell startup/profile script,

This is interesting approach. Although, not without issues:

  1. Does shell profile run on any command (i.e. when you do wsl something, not just wsl)?
  2. This may make running any command in wsl slower
  3. This introduces an extra failure mode for user's commands when they want some unrelated task
  4. It's not consistent with our start-conf=auto so, we'll probably need to introduce start-conf=shell-profile or similar. And this has to be enabled manually? If it's not, we may eventually get into situation when edgedb is started both from profile and systemd for some user and it will make it mess to debug.

(2), and (3) can be shielded as much as possible from user by carefully spawning in background and hiding the output, but may still impose problems at times.

add a GUI on the Windows side like what docker desktop does, or

This is very similar to how we already handle windows from native context (i.e. we manage custom distro, support auto-start, etc.). Applying this to user managed distributions means trying to solve issues when user upgraded/removed the distribution, and also somehow keep in track global list of instances because clashes may be a problem, and deal with several other kinds of metadata synchronization errors between host system and distros.

automatically start the instance behind the scenes when edgedb is ran in a project folder containing the toml file.

We have discussed this multiple times. The problem that it only works when you use edgedb for running repl. But I think more common would be running an app instead. And users will see this as a bug ("repl is working, why my app couldn't connect few seconds ago?"). And if you want to start and instance for the app, instance start is more straightforward than running repl to start the instance.

So at this point, I'm not sure any of these are worth the effort. Given that we hint how to start an instance and it's easy to put that into the shell profile file if you wish.