Open Antosser opened 6 months ago
Hi @Antosser! Thanks so much for this PR. Can you please split concerns in two PRs please?
unwrap
removalscolor_eyre
(this needs extra discussion)Lets focus on merge 1 and then revisit 2 once 1 is merged!
color_erye
is pretty much just a drop-in replacement for anyhow
, but changing the imports over 25 files would still take some time. Why don't we discuss color_eyre
here and maybe swap it for something else once rather than doing it several times?
Hi @Antosser! Thanks so much for this PR. Can you please split concerns in two PRs please?
unwrap
removals
color_eyre
(this needs extra discussion)Lets focus on merge 1 and then revisit 2 once 1 is merged!
color_erye
is pretty much just a drop-in replacement foranyhow
, but changing the imports over 25 files would still take some time. Why don't we discusscolor_eyre
here and maybe swap it for something else once rather than doing it several times?
I rather focusing in each topic, makes PRs easier to review and also development in general easier to follow.
Given that we are writing this for the community, these kind of decisions needs some discussion on why
we need to migrate.
Can we focus in unwrap
s for this PR, please?
Can we focus in unwraps for this PR, please?
Rewriting everything right now would be a lot of work, just to probably undo it later. Let's discuss it first, so I won't have to do as many changes
I started a discussion for this: #427
I started a discussion for this: #427
Nice! Let's just remove unwraps in this PR please, so we can merge it!
@EstebanBorai
Let's just remove unwraps in this PR
Wdym?
@Antosser in this PR you add color_eyre which is out of the scope of this issue (#424).
Please revert that change so we focus on unwrap
instances. Then, after merging, we can get back to color-eyre
as alternative.
As I've said, migrating back to anyhow
is not as simple as find&replacing the Result
structs, and it would take some time. Besides, I have no idea how to revert a commit from a PR in another PR, so it would be essentially double the work. I've also implemented some eyre
-specific stuff, like suggestions, which would get lost in a migration back to anyhow
. Let's discuss color_eyre
first, before making huge changes
As I've said, migrating back to
anyhow
is not as simple as find&replacing theResult
structs, and it would take some time. Besides, I have no idea how to revert a commit from a PR in another PR, so it would be essentially double the work. I've also implemented someeyre
-specific stuff, like suggestions, which would get lost in a migration back toanyhow
. Let's discusscolor_eyre
first, before making huge changes
I think I can help you. I will open a PR addressing #424. Then we merge and we can rebase against this. WDYT?
To be specific, in this PR we are addressing 2 concerns that are strongly mixed.
Each error message should be handled and must provide a clear path for the user to address the error/warning.
Reviewing this PR correctly its highly time consuming and that could easily be tackled by maintaining each PR scoped to a single concern.
Then we merge and we can rebase against this. WDYT?
sure
Reviewing this PR correctly its highly time consuming
Yeah, it's a lot
that could easily be tackled by maintaining each PR scoped to a single concern
How? The amount of changes will stay the same. Only difference is that the error-handling library will be the same as before. Migrating back would take me much more time than for you to review this
This PR is a lot. I've completely swapped
anyhow
withcolor_eyre
, and replaced mostunwrap
s with?
. Such changes required changing multiple function signatures and struct fields.Now, the errors should look way better than they did before.
Examples
Before
After
Before
After
Also #425