-
-
Notifications
You must be signed in to change notification settings - Fork 4.4k
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
💫 Improve "spacy download" and support for different installation prefixes #1456
Comments
Also related and could be included in the same enhancement to #1373: python -m spacy download should not overwrite an existing model of the same name
|
FWIW, for me I'm a bit confused about @honnibal's description of #1220 as being an issue about Python being installed into a different prefix. |
Facing same issue:
I tried
|
Use #egg=model==version to allow pip to check for existing installations. The download is only started if no installation matching the package/version is found. Fixes a long-standing inconvenience.
Treat all additional arguments passed to the download command as pip options to allow user to customise the command. For example: python -m spacy download en --user
This thread has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs. |
Currently
spacy download
seems to struggle when Python is installed into a different prefix. See #1220 .Possible resolutions could include an argument to
spacy download
. Ideal resolution would be detecting the correct prefix, and installing there.If you work on this, please try to pay attention to cross-platform and cross-version support. Try to use the built-in
pkg_resources
module. The tools inspacy.compat
might assist with this. Usingpathlib.Path
for file-system manipulation is also helpful.The text was updated successfully, but these errors were encountered: