Not working across OS X and Linux?

[AllanLRH]

Doesn't seem to be working accross OS X and Linux? Path to Python seems to be hardcoded – any suggest workarounds will be greatly appreciated :)

I often work on a remove server, sometimes issuing command in the ssh terminal (Linux, Bash), and at other times in my local terminal (OS X, Zsh), since I also mount the relevant folders using sshfs.

nbstripout seems to be working fine on the platform on which run nbstripout --install, but crashes on the other (and crashes commands such as git status and git diff). The behavior is the same whether I run the install-command on Linux and test on OS X, or vice versa.

Example output (from Linux, install-command on OS X):

$ git status
/Users/allan/homeInstalled/miniconda3/envs/py35/bin/python /Users/allan/homeInstalled/miniconda3/envs/py35/lib/python3.5/site-packages/nbstripout.py: 1: /Users/allan/homeInstalled/miniconda3/envs/py35/bin/python /Users/allan/homeInstalled/miniconda3/envs/py35/lib/python3.5/site-packages/nbstripout.py: /Users/allan/homeInstalled/miniconda3/envs/py35/bin/python: not found
error: external filter /Users/allan/homeInstalled/miniconda3/envs/py35/bin/python /Users/allan/homeInstalled/miniconda3/envs/py35/lib/python3.5/site-packages/nbstripout.py failed -1
error: external filter /Users/allan/homeInstalled/miniconda3/envs/py35/bin/python /Users/allan/homeInstalled/miniconda3/envs/py35/lib/python3.5/site-packages/nbstripout.py failed
fatal: tryLoadData/tryLoadData.ipynb: clean filter 'nbstripout' failed

Example output (from OS X, install-command on Linux):

(py35) ❯ git status
/lscr_paper/allan/miniconda3/envs/msth/bin/python /lscr_paper/allan/miniconda3/envs/msth/lib/python3.5/site-packages/nbstripout.py: /lscr_paper/allan/miniconda3/envs/msth/bin/python: No such file or directory
error: external filter /lscr_paper/allan/miniconda3/envs/msth/bin/python /lscr_paper/allan/miniconda3/envs/msth/lib/python3.5/site-packages/nbstripout.py failed -1
error: external filter /lscr_paper/allan/miniconda3/envs/msth/bin/python /lscr_paper/allan/miniconda3/envs/msth/lib/python3.5/site-packages/nbstripout.py failed
fatal: tryLoadData/tryLoadData.ipynb: clean filter 'nbstripout' failed

[kynan]

That's a tricky one: the path to the Python interpreter and nbstripout are indeed hard coded - deliberately. The point is to make the filter work independently of the environment where it is run (i.e. where you run git).

When using conda environments / virtualenv, nbstripout is installed with a prefix that may not be in the $PATH of your default shell environment. Hence using the filter in that environment would fail if we were just calling nbstripout.

Do you have a good idea for how to resolve this?

[AllanLRH]

Hmmm, I'm not that well versed in the internal mechanisms of git (./git/info/attributes and .attributes was news to me), but my best bet it to place a Python-script alongside the attributes-file, which returns the path of the relevant Python-interpreter (or print to stdout, in order to allow for Perl and bash scripts as well). The script could

1. Return a hard-coded path, thus replicating the current behavior – this could be the default behavior, and should be generated by the same mechanism as currently done be nbstripout --install.
2. Return a path dependent on the machine executing the script – like checking name of the OS, the contents of the PATH-variable etc… the user would be responsible for cooking up this script up himself.

The scripts should not be pushed to the remote, but be confined to the local instance of the repo, thus allowing users to use more "hack-ish" solutions :)

What do you think?

[kynan]

Suppose we could have a wrapper script checking for existence of

1. nbstripout in the $PATH
2. the hard-coded script path from nbstripout --install

Maybe in reverse order...

[kynan]

FYI, since nbstripout can now be run as a module, we have changed the filters to use /path/to/your/python -m nbstripout i.e. it's still the full path to the interpreter, but no longer to the nbstripout entry point script. Does this help @AllanLRH ?

[mereldawu]

I have a similar issue, and my set up is

• Local is OS X (zsh)
• Remote is Linux container
• nbstripout 0.3.9.
• Also mount the relevant folders.

I first installed it in my local, but when I try to use nbstripout --install I'm receiving the following error:

command not found: nbstripout. 

Then I installed nbstripout inside the container and can use it without a problem.

But then when I do git status again in my local, I get the following error:

"/opt/conda/bin/python3.8" -m nbstripout: /opt/conda/bin/python3.8: No such file or directory
error: external filter '"/opt/conda/bin/python3.8" -m nbstripout' failed 127
error: external filter '"/opt/conda/bin/python3.8" -m nbstripout' failed

I like using zsh on my local for git since I have all the zsh customisation, but it's not a big issue. Just thought I'd put it here, in case there's some easy way of resolving it.

[kynan]

@mereldawu, is /opt/conda/bin inside the container? The interpreter path is written at the point where you run nbstripout --install and the path of the active interpreter is used.

[mereldawu]

I realised instead of using nbstripout directly, I can just use python -m nbstripout on my local. Thanks for the awesome tool!

[kynan]

Great to hear you found a working solution!

[mafloh]

I had a similar error:

zsh: /usr/local/bin/nbstripout: bad interpreter: /usr/local/opt/[email protected]/bin/python3.9: no such file or directory

I solved it by changing /usr/local/bin/nbstripout and replacing the shebang line with #!/usr/local/bin/python3. To find out the location of your python interpreter I did: which -a python3.

I had deinstalled python3.9 because of problems with homebrew because of M1.

Please Note: I am not sure how hacky this approach is. It solved the issue for me for now.

[kynan]

@mafloh that should be fine, as long as you always have nbstripout installed for your system python3.

Hard coding the interpreter path is a feature of entrypoint scripts as it's the only way to make sure the script is going to use the "right" interpreter. If you then uninstall said interpreter there's not much that could be done to avoid this failure...

FWIW, the alternative would have been to reinstall nbstripout with your system python3.