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

Define all errors in ./src/huggingface_hub/errors.py #2069

Closed
Wauplin opened this issue Feb 29, 2024 · 8 comments
Closed

Define all errors in ./src/huggingface_hub/errors.py #2069

Wauplin opened this issue Feb 29, 2024 · 8 comments
Labels
good first issue Good for newcomers

Comments

@Wauplin
Copy link
Contributor

Wauplin commented Feb 29, 2024

Custom exceptions are defined in various places across the codebase. For consistency, we should define them all in ./src/huggingface_hub/errors.py.

Requested by @albertvillanova in huggingface/datasets#6296.

@Wauplin Wauplin added the good first issue Good for newcomers label Feb 29, 2024
@Y4suyuki
Copy link
Contributor

Hi, I'm interested in taking on this issue. It seems like a great starting point for me.

@Wauplin
Copy link
Contributor Author

Wauplin commented Mar 10, 2024

Hi @Y4suyuki, thanks for proposing your help on this issue! Do you need any additional information before giving it a try or is it clear? Happy to review a PR or answer any questions. I do think it'd be best to start a PR only with a few errors and then extend it once we've agreed on how to proceed. Thanks in advance!

@Y4suyuki
Copy link
Contributor

Y4suyuki commented Mar 16, 2024

Hi @Wauplin , I've created a PR that moves several custom errors into errors.py.

I have one question:
Do functions closely related to errors, like _parse_text_generation_error , also need to be moved to errors.py or errors.py simply cotntains custom errors only?

I thought errors.py should simply contains custom errors and implemented so in PR but I'm asking just in case.

@Wauplin
Copy link
Contributor Author

Wauplin commented Mar 18, 2024

Do functions closely related to errors, like _parse_text_generation_error , also need to be moved to errors.py or errors.py simply cotntains custom errors only?
I thought errors.py should simply contains custom errors and implemented so in PR but I'm asking just in case.

Yes, you're absolutely right! We only want errors to be defined in errors.py. Any other logic might be hard to maintain if it causes circular imports for example. So let's keep errors.py minimal as you did in the PR. Thanks for your contribution and kicking off this topic!! 🔥

@010kim
Copy link
Contributor

010kim commented Aug 9, 2024

@Wauplin Hello! I'm relatively new to this repository, and I want to help and contribute. I see that the commits above have worked on a lot of the errors already. Is there any errors left that I can work on? Or any places in the repository likely to have custom errors?

@Wauplin
Copy link
Contributor Author

Wauplin commented Aug 12, 2024

Hi @010kim, thanks for proposing your help! All errors have not yet been transferred to errors.py no. A good contribution would be to move the errors from ./utils/_errors.py to it. Would you like to open a PR for it? Note that all the logic for def hf_raise_for_status would have to stay in the current module and not be moved with the other errors. Let me know if you have any question!

@Wauplin
Copy link
Contributor Author

Wauplin commented Aug 27, 2024

I think we're now done with this issue :) Thanks everyone involved in solving it! It has been a nice community effort in #2122, #2170, #2202, #2444, #2470 and finally #2474 🤗

@julien-c
Copy link
Member

julien-c commented Sep 2, 2024

great job!

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

No branches or pull requests

4 participants