Spacy: spacy-lookups-data conda package creates spacy_lookups entry points as console scripts

[geektoni]

How to reproduce the behaviour

I have installed spaCy inside my conda environment by following the instructions provided by the official website https://spacy.io/usage. I obviously selected the instructions for conda. However, I have noticed that the spaCy package causes a conflict with the bash command tr. Below the error that appears:

(spacy) geektoni@uriel:~/Github/spacy$ tr
Traceback (most recent call last):
  File "/home/geektoni/miniconda3/envs/spacy/bin/tr", line 10, in <module>
    sys.exit(tr())
TypeError: 'dict' object is not callable

This happens because spaCy install inside the bin directory of the conda environment an executable called tr and this will be called instead of the "standard" tr (calling which tr results in /home/geektoni/miniconda3/envs/spacy/bin/tr instead of /usr/bin/tr)
The following steps can be used to reproduce the error:

conda create -n spacy python=3.6
conda activate spacy
conda install -c conda-forge spacy
conda install -c conda-forge spacy-lookups-data
python -m spacy download en_core_web_sm
tr # This will cause the error

Your Environment

• Operating System: Ubuntu 18.04
• spaCy version: 2.2.3
• Platform: Linux-5.0.0-37-generic-x86_64-with-debian-buster-sid
• Python version: 3.6.9

[ines]

I'm confused where the tr executable comes from... the only executable included with spaCy is bin/spacy (see here). We don't have a bin/tr in the repo either (see here).

Can you share the contents of that file?

Edit: Ah, maybe this is caused by entry points in your conda environment? The spacy-lookups-data package exposes an entry point tr (for the Turkish language data) that spaCy can read from. But those are under our own namespace, spacy_lookups. As far as I know, entry points are only installed as Python executables if they're defined as console_scripts... but maybe this is somehow related to how the conda-forge build is set up?

Edit 2: Okay, pretty sure this is related to the conda package setup – see the conda-forge meta.yaml. It's not defining the entry point group correctly, so the entry point is interpreted as a console script. Whereas the package's setup.cfg correctly defines the entry points as part of the group spacy_lookups (see here).

Edit 3: Now we only need to find out how to define non-console scripts entry points for conda 🤔 The examples only show top-level entry points for console scripts...

[honnibal]

This was a nasty problem! So apparently the entry-points block in Conda is somewhat misnamed. When the schema was first defined, the developer wasn't really thinking about non-script entry-points as a feature, because it didn't work very well at the time: https://github.com/conda/conda/issues/404

The entry-points block has kept the confusing name ever since. So that's how I fell into the trap: we advertise those entry-points, but when I added them under the entry-points group, they were installed as console scripts by conda :(.

We should have a new build up soon: https://github.com/conda-forge/spacy-lookups-data-feedstock/pull/5

I use tr quite often myself, but I don't really use Conda...I guess it's lucky that there's no ls country code.

[geektoni]

https://github.com/conda-forge/spacy-lookups-data-feedstock/pull/5 managed to fix the issue! tr works again now. Thank you for the quick reply and support! :dancer:

[lock[bot]]

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.