Repurposed `edgedb info` command for bug-tracking

[tailhook]

The command should at least report:

1. CLI version and architecture
2. EdgeDB version
3. OS kind and version

Additionally we may try to detect bindings:

• If Cargo.toml is present, run cargo tree
• If package.json is present, run nmp list...

I'm not sure how reliable and expected is to run package manager from command, but with the detection, we can try add links where to report bugs:

$ edgedb bug-report
Information to paste into bugtracker:
  CLI Version: 2.5 x86_64
  EdgeDB version: 2.7+deadbee
  OS: Windows 10.2 x86_64
  Node version: 15.2
  edgedb-js version: 2.0.0

Links to report to:
* JavaScript bindings, query builder, data encoding: https://github.com/edgedb/edgedb-js/
* Installation, Administration, REPL: https://github.com/edgedb/edgedb-cli/
* Queries, migration issues, server errors: https://github.com/edgedb/edgedb/

Questions:

1. Should we detect languages?
2. Is it okay to have an interactive command? I.e. should we ask interactively if users want's to run npm and things?
3. The name: should it be edgedb bug-report, edgedb ver or edgedb versions?

[raddevon]

This looks rad, @tailhook. Addressing your questions:

1. I like the idea of detecting the language. The less work we leave for the user, the more likely they are to report and the greater the likelihood we get all the information we need to process it.
2. It seems fine for it to be interactive. Even if someone wants to do an automated bug report for some reason, we probably don't want to support that. That said, should we even ask permission? I assume we'll just be listing installed versions of packages. I'm inclined to just do it without asking permission unless there is a potential for a problem I'm just not foreseeing.
3. I like the more verbose edgedb versions. I believe that would be easier to remember.

If we wanted to go a step further, we could pre-populate the issue with the info using query parameters. Makes it even more likely we'll get the report and it will have what we need, formatted the way we expect.

[tailhook]

I'm inclined to just do it without asking permission unless there is a potential for a problem

Off the top of my head:

1. User being in the wrong virtualenv or whatever it is called in some languages. It's mostly python problem, though. There is NVM for node but I'm not sure if that is used often.
2. npm vs yarn usage. I'm not sure if there will be issue for python (poetry, whatever). Java has some maven/sbt dilemma, but I'm not sure if that applies to us.
3. Also package.json can be for frontend that this user never recompiles. So npm might not be even installed.
4. Package managers can run arbitrary code from repo/dependencies. So if you did git clone; edgedb bug-report on untrusted repo, it may compromise your system.

3. I like the more verbose edgedb versions. I believe that would be easier to remember.

What do you think about edgedb bug-report name used in title?

If we wanted to go a step further, we could pre-populate the issue with the info using query parameters.

Few concerns:

1. Probably nice for terminals where we can add hidden links. Bad for other terminals (where link takes few lines and can be broken by terminal multiplexer/scrolling).
2. Is it just for bug report? I.e. how can user choose the template?
3. We can only put full body of the issue as far as I can see, not just placeholders with system info. So now templates for each of the repo have to be synchronized to the CLI and client has to be up to date.

[raddevon]

Re: permission to run package manager: Sounds like asking permission to run the package manager is the way to go. Maybe you could choose yarn if you find a package.json plus a yarn lockfile and NPM otherwise, but I'm not sure of a good way to mitigate the other drawbacks you mentioned.

Re: command: edgedb bug-report sounds great!

Re: query params: We would need to add the template as a query param. That might mean we would need to offer the user a link per issue template and let them choose which link to use. Both of your other points are valid and make me thing this probably isn't worth pursuing for a marginal reduction of friction.

[1st1]

Why can't all of this be part of edgedb info output?

[tailhook]

@raddevon

Re: query params: We would need to add the template as a query param. That might mean we would need to offer the user a link per issue template and let them choose which link to use. Both of your other points are valid and make me thing this probably isn't worth pursuing for a marginal reduction of friction.

I thought we direct them to the https://github.com/edgedb/edgedb-cli/issues/new/choose page, that allows them to choose? Or is it too many steps?

@yury

Why can't all of this be part of edgedb info output?

Current output of info is:

$ edgedb info
EdgeDB uses the following local paths:
┌────────────┬───────────────────────────────────────┐
│ Cache      │ /home/admin/.cache/edgedb/            │
│ Config     │ /home/admin/.config/edgedb/           │
│ CLI Binary │ /home/admin/.local/bin/edgedb         │
│ Data       │ /home/admin/.local/share/edgedb/data/ │
│ Service    │ /home/admin/.config/systemd/user/     │
└────────────┴───────────────────────────────────────┘

Do you propose this:

$ edgedb info
EdgeDB uses the following local paths:
┌────────────┬───────────────────────────────────────┐
│ Cache      │ /home/admin/.cache/edgedb/            │
│ Config     │ /home/admin/.config/edgedb/           │
│ CLI Binary │ /home/admin/.local/bin/edgedb         │
│ Data       │ /home/admin/.local/share/edgedb/data/ │
│ Service    │ /home/admin/.config/systemd/user/     │
└────────────┴───────────────────────────────────────┘

Information to paste into bugtracker:
  CLI Version: 2.5 x86_64
  EdgeDB version: 2.7+deadbee
  OS: Windows 10.2 x86_64
  Node version: 15.2
  edgedb-js version: 2.0.0

Links to report to:
* JavaScript bindings, query builder, data encoding: https://github.com/edgedb/edgedb-js/
* Installation, Administration, REPL: https://github.com/edgedb/edgedb-cli/
* Queries, migration issues, server errors: https://github.com/edgedb/edgedb/

Or do you propose edgedb info --bug-report ?

Currently info provides very different info that is useful only locally. So we have to restructure it. Having extra options to info for this task can be inconvenient. And making info interactive is a breaking change, although probably minor.

Also note that edgedb bug-report needs a database connection. So has all connection options (looks like fine for info too, as that doesn't have any options so far).

[raddevon]

@tailhook

I thought we direct them to the https://github.com/edgedb/edgedb-cli/issues/new/choose page, that allows them to choose? Or is it too many steps?

Even just having a one-stop shop to get all the info they need is already going to make the user's process easier. Anything beyond that is icing on the cake.

They're going to need to choose what type of bug report somewhere. It probably doesn't make much difference if they're choosing from a few buttons in the Github UI or from a list of links in the CLI. I'd go with the latter if pre-filling via query parameters were practical since that would further reduce fiction, but it sounds like that isn't going to be super practical. Given that, I think sending them to the URL you propose will be fine.

[tailhook]

We discussed this on the call yesterday. The summary is:

1. We repurpose edgedb info to output bug report info primarily
2. edgedb info default output is not machine-readable so it's okay to change the output
3. We add edgedb info --paths for the old output
4. edgedb info --get works both for paths and for versions
5. We don't do discovery of the language bindings just yet (too much to support all the bindings, for not so big profit at our current scale)
6. We print all bugtracker addresses on edgedb info --bugtrackers, but not in the default output.
7. We suggest extra things (--paths, --bugtrackers) at the bottom of the default output.