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

Open
Wauplin opened this issue Feb 29, 2024 · 4 comments
Open

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

Wauplin opened this issue Feb 29, 2024 · 4 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!! 🔥

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

2 participants