Project-level configuration file

[nsidnev]

The continuation of the discussion started at https://github.com/dmgolembiowski/edgemorph/issues/1.

The default path for EdgeDB schemas and migrations may not always be the best solution. At least because of personal preference. Yes, now it is possible to specify a custom path to the directory, but using the flag is not very convenient.

How about adding a project level EdgeDB config file? Something like edgedb.toml. With the ability to add various parameters there, which can be specified through the CLI flags, perhaps even with support for different environments.

The ability to specify instance name/DSN and the path to the directory with esdl/edgeql files will be especially useful.

.
├── app
│   └── __init__.py
├── tests
│   └── __init__.py
├── priv
│   └── edgedb
│       ├── app.esdl
│       └── migrations
├── edgedb.toml
├── poetry.lock
└── pyproject.toml

An example content of edgedb.toml(the rest of keys that are available through the CLI in the form of flags can also placed here, if necessary):

[global]
schema_dir = "./priv/edgedb"

[envs.prod]
instance = "production"

[envs.dev]
dsn = "edgedb://localhost/edgedb"

[tailhook]

Not sure we are ready to do this now, but let's keep keep track of things needed to be in project config here.

Short-term concerns:

1. Relying on toml in language bindings is not pretty. Or is it only for CLI? I think you have your own CLI in edgemorph, so you can wrap and use flags
2. Each extra in the project root (after perhaps 3) makes every project a little bit uglier. This is especially bad for monorepos which we probably will have to write special code for if we keep file in the root. Using --dir that contains all the necessary configs should work reasonably well for monorepos (and default directory for non monorepos). But this is probably a little bit subjective.

Also see https://github.com/edgedb/edgedb/discussions/1789

[dmgolembiowski]

I believe proto3 lends itself well to EdgeDB project-level configurations.

proto3 use[s] the protocol buffer language to structure your protocol buffer data, including .proto file syntax and how to generate data. --https://developers.google.com/protocol-buffers/docs/proto3 The language's structure is designed to be passed around network services:

syntax = "proto3"
service FooService {
rpc GetSomething(FooRequest) returns (FooResponse);
}

Here's an older example that compiles to Python code:

syntax = "proto2";

package tutorial;

message Person { optional string name = 1; optional int32 id = 2; optional string email = 3;

enum PhoneType { MOBILE = 0; HOME = 1; WORK = 2; }

message PhoneNumber { optional string number = 1; optional PhoneType type = 2 [default = HOME]; }

repeated PhoneNumber phones = 4; }

message AddressBook { repeated Person people = 1; }

and it becomes:
```python
class Person(message.Message):
  __metaclass__ = reflection.GeneratedProtocolMessageType

  class PhoneNumber(message.Message):
    __metaclass__ = reflection.GeneratedProtocolMessageType
    DESCRIPTOR = _PERSON_PHONENUMBER
  DESCRIPTOR = _PERSON

class AddressBook(message.Message):
  __metaclass__ = reflection.GeneratedProtocolMessageType
  DESCRIPTOR = _ADDRESSBOOK

[tailhook]

We now have a project-level configuration file https://www.edgedb.com/blog/introducing-edgedb-projects