Tracking issue: pre-release fixes

[marcoow]

• improve CLI for nicer output: Improve CLI output #28
• add generators for entity (add example load/create functions, changeset with validations, etc.), entity test helpers, middleware, controller + controller test: Generators for entities, entity-test-helpers, middleware, controllers, controller-tests #26
• add testing for pacesetter itself: Add tests #30
• move validation into db crate: move validation into db crate #21
• add some sort of factory crate for creating test data in tests – Fake data generation #23
• add example and functionality for transactional behavior – introduce transactions #22
• add update endpoint to full example (parse request payload into changeset -> pass that to update function, return record – just like creation essentially) – se add update example #25
• add deletion endpoint to full example – see add deletion example #24
• convert from mini meta framework to generator library – see inline pacesetter code into generated project #38
• switch everything to cargo nextest potentially (not for now)
• switch everything to googletest potentially – see switch to googletest for better assertions #41
• add proper READMEs to blueprints – see Add READMEs to blueprint #72
• add proper README for pacesetter itself – see add README and LICENSE #48
• write API docs (as well as some code comments for the example application) – see Add code docs #49
• rename to gerust and give Florian Gilcher credit for the name in the README – see rename pacesetter to gerust #99
• move to mainmatter/gerust (for now – might be moved to the gerust GitHub org later)
• publish crate as 0.0.1-alpha.1 – see https://crates.io/crates/gerust
• add some kind of logo to the README
• write full tutorial:
  • project briefly
  • add task entity
  • add migration, run migration
  • add endpoints for reading tasks
  • add tests
  • add user entity
  • require auth for task modification via middleware
  • add tests
• build landing page

---

• improve the landing page with better design etc.
• use better favicon (current one looks a bit strange)
• come up with a better name…

[marcoow]

@LukeMathWalker I merged #32 and updated the above list. Some thoughts:

• switch everything to cargo nextest potentially
• switch everything to googletest potentially

I was thinking if we recommend nextest and googletest generally, I think we should migrate this repo as well to be in sync with that recommendation. I guess that's relatively straight forward to do (if we want to)?

• add proper READMEs to blueprints (in particular explaining the endpoints for the full blueprint)

If you generate an app based on the blueprints, it should also generate a README that explains the structure of the repo, what goes where, what generators are available for generating more things, etc.

• write guide/tutorial

I think sth. like the Pavex Quickstart is really the essential part of the documentation. API docs are fine but in particular in the case of a library like this, not essential.

• set up marketing landing page
• come up with a better name…

These are the very last steps I'd say once everything else is done. We should definitely set up a landing page with a nice design, etc.

---

I think before any of the above tasks, it'd be good if you bould review everything that exists so far so that we can fix any problems there might be (and I'm sure there will be a few…)

[LukeMathWalker]

I was thinking if we recommend nextest and googletest generally, I think we should migrate this repo as well to be in sync with that recommendation. I guess that's relatively straight forward to do (if we want to)?

googletest is a straight-forward migration, yes.
I need to review DB tests to see how straight-forward it is to migrate to cargo nextest.

I think both are more nice-to-haves than essentials.

[LukeMathWalker]

I think sth. like the Pavex Quickstart is really the essential part of the documentation. API docs are fine but in particular in the case of a library like this, not essential.

Where should this be hosted?
Do you want me to setup something with Material for mkdocs, as I did for Pavex? @marcoow

[marcoow]

Where should this be hosted?

I'd say GH Pages, Netlify – sth. simple like those

Do you want me to setup something with Material for mkdocs, as I did for Pavex? @marcoow

That would be good, yes 👍

[marcoow]

Let's not prioritize googletest and nextest then and get everything else done first

[BobrImperator]

I'm trying out pacesetter right now and there's some nuances I've found so far:

For the record, since it's not published yet, I've installed it from git CARGO_NET_GIT_FETCH_WITH_CLI=true cargo install --git ssh://[email protected]/marcoow/pacesetter.git

Notes:

• After installation, the command name is pace instead of pacesetter
• docker-compose.yml has hardcoded database name, user, password.
  • .env files hould define DATABASE_NAME, DATABASE_PASSWORD, DATABASE_USER variables and they should be used in the docker_compose.yml for spinning up the postgres instances.
• ui#error method should always return error details. I think instead of --debug there should be --silent option. When trying to call cargo run --bin db create it'd only say "Could not create database!" without providing any reason.
• When a project is scaffolded with --full, the only callable project with cargo run --bin is the web project.
  In order to call other ones, they must be added to default-members in the root Cargo.toml manually.
• Running cargo run --bin web by default will not compile.
  The import in main.rs is not translated

error[E0432]: unresolved import `my_app_web`                                                                                                                                                              │
 --> web/src/main.rs:1:5                                                                                                                                                                                  │
  |                                                                                                                                                                                                       │
1 | use my_app_web::{init_tracing, run};                                                                                                                                                                  │
  |     ^^^^^^^^^^ use of undeclared crate or module `my_app_web

• cargo test by default fails.
  • Missing insta dependency for the cli project
  • migrations in tests seem to not run

---- tasks_test::test_delete_unauthorized stdout ----
thread 'tasks_test::test_delete_unauthorized' panicked at web/tests/api/tasks_test.rs:335:10:
called `Result::unwrap()` on an `Err` value: DbError(error returned from database: relation "tasks" does not exist

Caused by:
    relation "tasks" does not exist)

error[E0432]: unresolved import `insta`
   --> cli/src/util/ui.rs:162:9
    |
162 |     use insta::assert_snapshot;
    |         ^^^^^ use of undeclared crate or module `insta`

[marcoow]

After installation, the command name is pace instead of pacesetter

That's intended – the name might change before release though

When a project is scaffolded with --full, the only callable project with cargo run --bin is the web project.
In order to call other ones, they must be added to default-members in the root Cargo.toml manually.

So you run the web bin with just cargo run (or the tests with cargo test). In order to run the other tools, you can just do cargo generate or cargo db (see .cargo/config.toml)

Missing insta dependency for the cli project

fixed: #47

migrations in tests seem to not run

You need to run the migrations before running the tests – some might say that's bad, I say it's a feature: cargo db migrate -e test