scripts have wrong interpreter after "conda install nibabel" in Windows

[yarikoptic]

Was trying to reproduce datalad/datalad#3116 on a freshly installed Window$ machine. Installed miniconda, created "datalad-dev" conda environment.
In regular "Anaconda Prompt" which seems to be running pure Windows cmd prompt, doesn't find/run nib-ls at all (regular entrypoint mechanism installed apps like datalad seems to work fine, but somehow it just ended up in /usr/bin/datalad using regular /usr/bin/python for interpreter -- yet to figure things out). If I start bash within it, then I get

/mnt/c/Temp/datasets.datalad.org/openneuro/ds000114$ nib-ls
-bash: /mnt/c/Users/XXX/AppData/Local/Continuum/miniconda3/envs/datalad-dev/Scripts/nib-ls: C:/Users/XXX/AppData/Local/Continuum/miniconda3/envs/datalad-dev/bin/python: bad interpreter: No such file or directory

well -- first of all the problem is that path is windows path so not sure if this bash could comprehend it. Then, the python is actually available not under /bin but /mnt/c/Users/XXX/AppData/Local/Continuum/miniconda3/envs/datalad-dev/python.exe

But even if I correct shebang to be a correct windows path -- it would not run in bash, and remains (well, there is no .exe etc I guess) not found by windows cmd. But even if I fix the path to be a full path to python.exe POSIX style I can't run it in that bash

/mnt/c/Temp/datasets.datalad.org/openneuro/ds000114$ nib-ls
C:\Users\XXX\AppData\Local\Continuum\miniconda3\envs\datalad-dev\python.exe: can't open file '/mnt/c/Users/XXX/AppData/Local/Continuum/miniconda3/envs/datalad-dev/Scripts/nib-ls': [Errno 2] No such file or directory

@chrisfilo - do you have recollection on how nibabel was installed and what you have in your shebang for it?

[yarikoptic]

holy cow, or something to learn every day... apparently that "bash" I am running is coming from WSL Debian which I just installed (I thought it would be some conda env bash). So the system wide datalad is because I apt-get installed it there. But then it still has access to conda environment outside (I guess env variables preserved) and thus all the mess. The issue remains though -- when I installed nibabel via conda, scripts aren't available for execution in regular Anaconda Prompt

[effigies]

@yarikoptic How does it do if you install in your conda environment via pip? And does choosing an older version of nibabel make any difference? This might be more of a conda packaging problem. Conda's Windows builds have become very averse to nibabel, so we're using noarch, but that might not be installing scripts correctly.

[pauldmccarthy]

I'm not a conda expert by any means, but it may just be a matter of explicitly adding the entry points to the conda-forge recipe, e.g.:

build:
    noarch: python
    number: 0
    script: "{{ PYTHON }} -m pip install . -vv"
    entry_points:
      - nib-ls = nibabel.cmdline.ls:main
       ....

[effigies]

We could give it a try. Do you have experience with building conda packages that can be installed without uploading to conda-forge first?

[pauldmccarthy]

Sure, I'm currently involved in a fight between conda-forge and fsleyes... I'll have a play now, and PR conda-forge/nibabel-feedstock.

[yarikoptic]

@yarikoptic How does it do if you install in your conda environment via pip?

oh - it has been ages (months) since I have touched that exotic windows system. I will try to regain access to it if needed

[yarikoptic]

I'm not a conda expert by any means, but it may just be a matter of explicitly adding the entry points to the conda-forge recipe,

I even happily forgot that we are indeed also defining entry points in datalad recipe

  entry_points:
    - datalad=datalad.cmdline.main:main
    - git-annex-remote-datalad-archives=datalad.customremotes.archives:main
    - git-annex-remote-datalad=datalad.customremotes.datalad:main

And I am the one saying around how conda-forge setup/recipes are so beautiful... and we have to duplicate entry points definitions in the recipes - I will start taking my words back!
So indeed, it might be necessary to do here. I wonder why they didn't automate that some how (e.g. monkey patching setuptools just for the sake of seeing what is provided as entrypoints in setup() call)

[matthew-brett]

At this stage, it would be fine to pull out the custom Windows script stuff. Everyone's using setuptools now.

[effigies]

By custom windows stuff you mean just stop using nisext in setup.py? I don't have any real concept of what that stuff's doing.