Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Relocate benchttp/cli to benchttp/engine #70

Open
2 tasks
moreirathomas opened this issue Mar 31, 2023 · 1 comment · May be fixed by #71
Open
2 tasks

Relocate benchttp/cli to benchttp/engine #70

moreirathomas opened this issue Mar 31, 2023 · 1 comment · May be fixed by #71
Assignees
Labels
needs specs Specifications are needed before assignation
Milestone

Comments

@moreirathomas
Copy link
Member

Description

For the foreseeable future, Benchttp will be meant to be used through the command line only.

We expect to improve the DX b having the cli code inside the main repository .

Tasks

  • relocate benchttp/cli code inside this repository
  • try to keep the best git history as possible
@moreirathomas moreirathomas added this to the v0.2 milestone Mar 31, 2023
@moreirathomas moreirathomas self-assigned this Mar 31, 2023
@GregoryAlbouy GregoryAlbouy added the needs specs Specifications are needed before assignation label Apr 1, 2023
@GregoryAlbouy GregoryAlbouy modified the milestones: v0.2, Next Apr 1, 2023
@moreirathomas
Copy link
Member Author

Pros/cons analysis:

Having all code under the same repo.

Pros

  • Unified CI/CD
  • Automatic integration of the core's new features and fixes inside the cli
  • Clearer PR and issue tracking
  • May help refactor (planned and emergent) by virtue of having all the code in one place
  • Matches more closely our new use case : Benchttp is a command line tool, there's not supported front end other than the cli. The CI job already depends on the cli.

Cons

  • Not as straight forward boundaries, but honestly independent packages should solve this issue

Keeping the cli and core code separated

Pros

  • Clear consumer/provider split, enforces I/O uncoupling
  • May evolve at a difference pace than the core
  • Would be good if we continue to support another front end than the cli (redoing the split is easy however)

Cons

  • No automatic features and fixes update
  • Must juggle two repositories
  • Artificial cut given the cli ought to be our only way of interacting with the core

@moreirathomas moreirathomas linked a pull request Apr 4, 2023 that will close this issue
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
needs specs Specifications are needed before assignation
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants