Partial rewrite tracker #50

noth commented 2025年04月25日 07:12:21 +02:00

After working on this for quite a bit of time last year, I've realized that this needs at least a partial rewrite and restructure.

TBD:

• restructure cli
• update forgejo-sdk

After working on this for quite a bit of time last year, I've realized that this needs at least a partial rewrite and restructure. TBD: - [ ] restructure cli - [ ] update forgejo-sdk

baskoro commented 2025年06月12日 04:43:21 +02:00

I've realized that this needs a rewrite, desperately.

Two questions:

• Why this deperately needs a rewrite?
• What's wrong with the current codebase?

And a question:

• How can I help with the rewrite process?

> I've realized that this needs a rewrite, desperately. Two questions: - Why this *deperately* needs a rewrite? - What's wrong with the current codebase? And a question: - How can I help with the rewrite process?

tranzystorekk commented 2025年06月13日 02:44:12 +02:00

@baskoro This project is practically discontinued, it used to be a place to experiment on top of https://codeberg.org/Aviac/codeberg-cli, but I would advise against spending any effort here

@baskoro This project is practically discontinued, it used to be a place to experiment on top of https://codeberg.org/Aviac/codeberg-cli, but I would advise against spending any effort here

noth commented 2025年06月13日 10:45:39 +02:00

Even though this used to be a playground for experimentation, I still would like to at least try to revive it.

A few reasons for a rewrite (a partial one, not from scratch) and a restructure:

• The current code relies on forgejo_sdk, which is actually and totally discontinued. I'd switch to forgejo-api by Cyborus, which is much better.
• The current code is disorganized, like having a cli folder and then additional pr and repo folders, with all of them containing both the cli structs and the implementation.
• I saw a lot of room for improvement in validation (like in auth::login, where there's first a split_whitespace then collect to vec then a length check on that vec, and then there's also a length check on the string. all of this can be !s.contains(" ") && s.len() == 40)
• I saw a lot of room for improvement in UX, particularly at points where stuff like spin_until_ready is used, which just creates a spinner, without an option for a message.

To be honest, I did go a bit overboard in the issue message, but in truth I just want this to be a useful tool, and have good UX and also good DX.

Good DX especially means (in the context of a CLI tool) that you can quickly find, without the knowledge of the codebase itself, where a given command is implemented, and I don't think that in the current state of the codebase, it'd be easy and quick to locate a command's implementation.

Going forward, I'd like to ask a question:
where would you put the CLI structs and where you would put the command implementations. Also, there is an option to colocate them, which could also be viable. But that is up for further debate.

Even though this _used_ to be a playground for experimentation, I still would like to at least try to revive it. A few reasons for a rewrite (a partial one, not from scratch) and a restructure: - The current code relies on forgejo_sdk, which is actually and totally discontinued. I'd switch to forgejo-api by Cyborus, which is much better. - The current code is disorganized, like having a cli folder and then additional pr and repo folders, with all of them containing both the cli structs and the implementation. - I saw a lot of room for improvement in validation (like in auth::login, where there's first a split_whitespace then collect to vec then a length check on that vec, and then there's also a length check on the string. all of this can be `!s.contains(" ") && s.len() == 40`) - I saw a lot of room for improvement in UX, particularly at points where stuff like `spin_until_ready` is used, which just creates a spinner, without an option for a message. To be honest, I did go a bit overboard in the issue message, but in truth I just want this to be a useful tool, and have good UX and also good DX. Good DX especially means (in the context of a CLI tool) that you can quickly find, without the knowledge of the codebase itself, where a given command is implemented, and I don't think that in the current state of the codebase, it'd be easy and quick to locate a command's implementation. Going forward, I'd like to ask a question: where would _you_ put the CLI structs and where you would put the command implementations. Also, there is an option to colocate them, which could also be viable. But that is up for further debate.

noth commented 2025年06月13日 11:25:34 +02:00

If you want to help contribute you can just fix bugs, since I am not currently able to write code, I am no help to the rewrite

If you want to help contribute you can just fix bugs, since I am not currently able to write code, I am no help to the rewrite