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

Change package name from "datasets" to something less generic #6053

Closed
geajack opened this issue Jul 19, 2023 · 1 comment
Closed

Change package name from "datasets" to something less generic #6053

geajack opened this issue Jul 19, 2023 · 1 comment
Labels
enhancement New feature or request

Comments

@geajack
Copy link

geajack commented Jul 19, 2023

Feature request

I'm repeatedly finding myself in situations where I want to have a package called datasets.py or evaluate.py in my code and can't because those names are being taken up by Huggingface packages. While I can understand how (even from the user's perspective) it's aesthetically pleasing to have nice terse library names, ultimately a library hogging simple names like this is something I find short-sighted, impractical and at my most irritable, frankly rude.

My preference would be a pattern like what you get with all the other big libraries like numpy or pandas:

import huggingface as hf
# hf.transformers, hf.datasets, hf.evaluate

or things like

import huggingface.transformers as tf
# tf.load_model(), etc

If this isn't possible for some technical reason, at least just call the packages something like hf_transformers and so on.

I realize this is a very big change that's probably been discussed internally already, but I'm making this issue and sister issues on each huggingface project just to start the conversation and begin tracking community feeling on the matter, since I suspect I'm not the only one who feels like this.

Sorry if this has been requested already on this issue tracker, I couldn't find anything looking for terms like "package name".

Sister issues:

Motivation

Not taking up package names the user is likely to want to use.

Your contribution

No - more a matter of internal discussion among core library authors.

@mariosasko
Copy link
Collaborator

This would break a lot of existing code, so we can't really do this.

@mariosasko mariosasko closed this as not planned Won't fix, can't repro, duplicate, stale Oct 3, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

2 participants