spacy.load should raise error if model not found

[coventry]

E.g. python -c 'import spacy; n = spacy.load("en_ansoteauhnotoheunatoheun")' runs without error

In [69]: import spacy
nlp = spacy.load('en_aosentnoteoeunt')
doc = nlp(u'They told us to duck.')
for word in doc:
    print(word.text, word.lemma, word.lemma_, word.tag, word.tag_, word.pos, word.pos_)


In [70]: 
In [71]: 
In [72]:    ....:    ....: (u'They', 0, u'', 0, u'', 0, u'')
(u'told', 0, u'', 0, u'', 0, u'')
(u'us', 0, u'', 0, u'', 0, u'')
(u'to', 0, u'', 0, u'', 0, u'')
(u'duck', 0, u'', 0, u'', 0, u'')
(u'.', 0, u'', 0, u'', 0, u'')

I assume the tag and pos values are not all supposed to be empty/zero. BTW, I get the same result even if I use nlp = spacy.load('en'), but that may be some kind of misconfiguration from installing it carelessly.

[coventry]

This was on an ubuntu 14.04 system with many other packages install. Doesn't happen on a fresh 16.04 so it's probably some kind of boring version skew.

[honnibal]

Thanks for updating after you debugged. I have that sort of problem with my Python environments a lot. The most common cause is if my PATH and PYTHONPATH variables are out-of-synch, so the pip command and python -m pip do something different.

Anyway. Relabelling this issue for a planned enhancement for v2. It's rubbish that the spacy.load() command silently "works" even if it doesn't...load. This behaviour has been preserved through the last few releases for backwards compatibility, but will be fixed for v2.

[ines]

Yes, I agree – for now, it'd be nice to at least print a warning if spacy.load() is called with a name that doesn't map to a model (the underlying functionality for checking that is all there). I'll have a look at this.

For v2.0, we should maybe consider explicitly encouraging importing models as packages for the default use case:

import en_core_web_sm
nlp = en_core_web_sm.load()

From the feedback we got so far, it turned out that a lot of users now actually prefer this way of loading the models over spacy.load(), as it's cleaner and more transparent, and lets you manage model dependencies like any other package dependency. As we publish more models, this will become more and more relevant. Especially production users might not want to rely on having the right model installed and mapped to an arbitrary name – instead, their application can explicitly require a specific version of a specific model.

[ines]

Fixed in v1.8.0!

[lock]

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.