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

Cleo 3.0 writeup #415

Open
Secrus opened this issue Mar 30, 2024 · 2 comments
Open

Cleo 3.0 writeup #415

Secrus opened this issue Mar 30, 2024 · 2 comments
Assignees

Comments

@Secrus
Copy link
Member

Secrus commented Mar 30, 2024

Below is a list of changes, required bugfixes and planned features for the next version of Cleo, Cleo 3.0. The list is not finished, it might evolve, change and expand. It's, basically, a download of my plans and ideas for Cleo.

Cleo 3.0 writeup

Docs

  • Rewrite docs from scratch
    • user docs
    • usage examples

New features

  • new CLI parser
  • introduce dynamic and static (user's choice) completions
  • introduce Powershell completions
  • introduce Tree UI component (extract the implementation from poetry show command)
  • replace the usage of rapidfuzz with difflib (dependent on new parser semantics)
  • remove namespace commands in favor of subcommands registered on commands (dependent on new parser semantics)
  • integration with logging
  • add helper functions for text transformations (colors, underline etc)

Refactorings

  • use @property.getter/@property.setter instead of get_*/set_* methods
  • UI components should be behind proxy UI() object instead of as methods on Command
  • Commands should not need Application reference
  • cleanup Windows support options into a separate module
  • help and list commands replacement (should be handled by the new parser)
  • colors and ansi escape sequences should be properly handled along with FORCE_COLOR/NO_COLOR and terminal features detection
  • strict API design (consider which methods/functions/classes need to be available and make stuff private/hidden, use __all__)
  • simplify lazy command loading (still easy to register new commands for poetry plugins)

Typing

  • remove all (or as much as possible) usage of optional types and Any
  • for types, all complex (more than 1 level deep) types should have a nice alias

To consider

  • drop event handling (cleo.events)

Misc

  • "inbox-zero" on issue tracker (aka resolve all issues)
  • test coverage in 90+% range

Best case scenario

This is a list of optional requirements that will not stop a release from happening if not completed

  • make highlighter extendable (json highlighting etc)
  • provide Protocols/hooks/base classes to easily modify or extend default behavior
  • dev docs with deep dive into inner works of every part of code

"I want to help!"

First of all, thank you.
Second, if you want to tackle one of the issues mentioned here or an issue from the issue tracker, please comment under this issue what you want to take care of. That will allow us to avoid duplicating our work. When in doubt, feel free to reach out in issues or on our Discord channel

@Secrus Secrus self-assigned this Mar 30, 2024
@Secrus Secrus pinned this issue Mar 30, 2024
@md384
Copy link

md384 commented May 30, 2024

I use cleo.events for a poetry plugin so dropping that would impact my and likely other poetry plugins (unless there is a replacement in mind). One specific use-case I use and might be common in other plugins, is to authenticate to a remote repository before running poetry commands.

@Secrus
Copy link
Member Author

Secrus commented May 30, 2024

@md384 thanks for your feedback. I didn't get to events yet, but there will surely be a new mechanism for this in Poetry if we decide to remove that from Cleo.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants