Normalize default dictionary location as $PREFIX/share/hunspell?

[bollwyvl]

Comment:

It appears that the semi-arbitrary ${PREFIX}/share/hunspell_dictionaries doesn't line up with other tools like enchant (as noted on conda-forge/pyenchant-feedstock#1), which expects ${PREFIX}/share/hunspell, nor does DICPATH support a delimited list of search paths.

Making this change here would lead to breakage in a number of downstream feedstocks:

Of note (namely the ones I don't personally co-maintain):

• @conda-forge/pyhunspell
  • would probably simplify the setup considerably
• @conda-forge/rstudio
  • no idea what's going on here, but apparently only build-time, so less worried

[asmeurer]

No idea where I got that path from conda-archive/conda-recipes@5a34409. I probably copied it from another package manager, but I might have also just made it up.

[bollwyvl]

Thanks for the history... good comments, too! I am hoping the bit about paths relative to the binary is no longer true... if we make the change, can certainly shore up some tests to verify the behavior, even if it takes a few tries to get it right.

[asmeurer]

If we're worried about breakage we could add a symlink. Might be good to check what path Linux package managers use.

[asmeurer]

I guess rereading the comment I probably just made it up. But why are other packages using hunspell? Did upstream hunspell get changed since the original recipe?

Also, assuming it hasn't, maybe it would be better to patch hunspell to add the path to the built-in list of paths rather than using the wrapper. The wrapper will break if someone wants to set a DICPATH of their own.

[bollwyvl]

why are other packages using hunspell

pyenchant will use hunspell as a backend.

other packages that want to work with hunspell put their dictionaries where hunspell-feedstock will find them.

symlink

Yes, that would work, as we don't have a windows build yet. This was verified over on conda-forge/pyenchant-feedstock#1 (comment)

patch hunspell to add the path to the built-in list of paths

if you see a clear path to supporting both that won't break downstreams, i'd say go for it!

[asmeurer]

Sorry, I mean why is enchant using ${PREFIX}/share/hunspell? Is that already standardized from somewhere else?

[bollwyvl]

why is enchant using

Dunno, but:

verified over on conda-forge/pyenchant-feedstock#1 (comment)

[asmeurer]

Well I think making this change (with a symlink for backwards compatibility) is a good idea. The symlink might break other builds that are also making that same symlink, but that will be easy to fix.

Longer term we should probably also try to update the package as I suggested here #12 (comment), or even upstream a fix to hunspell.

[bradbell]

Here is what works for me with using the current install of pyenchant:

podman pull continuumio/miniconda3
podman run -it continuumio/miniconda3 bash
conda config --add channels conda-forge
conda config --set channel_priority strict
conda install -y pyenchant
ln -s \
    $CONDA_PREFIX/share/hunspell_dictionaries  \
    $CONDA_PREFIX/share/enchant/hunspell
python 
import enchant
d = enchant.Dict("en_US")
ok = d.check("hello")
print( f'ok = {ok}' )

I have a package that can use pyenchant. Do you suggest that I make the install of my package change the CONDA_PREFIX directory by adding the soft link above ?