Opened 8 years ago

Last modified 5 years ago

#50608 new defect

py-jupyter: its subcommands are versioned, they should not

Reported by: akimd (Akim Demaille) Owned by: stromnov (Andrey Stromnov)
Priority: Normal Milestone:
Component: ports Version: 2.3.4
Keywords: Cc: stevecheckoway (Stephen Checkoway), Schamschula (Marius Schamschula), chrstphrchvz (Christopher Chavez), jjstickel (Jonathan Stickel)
Port: py-jupyter, py-notebook

Description

Hi,

$ jupyter-3.4 --help | tail -2
Available subcommands: 3.4 kernelspec-3.4 migrate-3.4 nbconvert-3.4
nbextension-3.4 notebook-3.4 trust-3.4

This is not normal, and as a result jupyter notebook fails, while it is expected to work. This is acknowledge by the core team here:

https://mail.scipy.org/pipermail/ipython-dev/2016-February/017064.html

Change History (14)

comment:1 Changed 8 years ago by stromnov (Andrey Stromnov)

Actually it's not a bug, but a side-effect of MacPorts naming convention and Jupyter name resolution.

MacPorts allows to coexist several python versions at the same time (for example 2.7, 3.4 and 3.5). And even explicitly requires to specify Python version at install time in terms of pyXY-* packages (most of py-* packages just an aliases for pyXY-* subports). Some python packages installs executable scripts in ${prefix}/bin, and MacPorts use special scheme (with suffixes -X.Y) to resolve naming clash (for example pytest from 2.7 and pytest from 3.5).

Jupyter executable doesn't know nothing about 'notebook', 'nbconvert' and other tools. Instead, Jupyter scans $PATH at runtime and selects all executables with pattern 'jupyter-*' and just allows to execute them.

So, you have py34-jupyter and py34-notebook packages, which installs ${prefix}/bin/jupyter-3.4 and ${prefix}/bin/jupyter-notebook-3.4 respectively. Which leads to 'jypyter-3.4 notebook-3.4' recipe instead of 'jupyter notebook'.

MacPorts already have OPTIONAL facility to 'select' specific package from sevaral alternatives (something like Ubuntu's 'update-alternatives'), which actually symlinks versioned files (-X.Y) to unversioned ones (see a bunch of *_select ports like ipython_select, cython_select).

It is possible to provide such 'selectable' packages for all Jupyter tools, but due to its OPTIONALITY it will require a tons of additional steps from users (one 'select' step for each package). Alternatively, it is possible to create one Jupyter meta-package with all dependencies (even rarely used) hardcoded and one 'select' package to select specific version.

comment:2 Changed 8 years ago by ryandesign (Ryan Carsten Schmidt)

Cc: stromnov@… openmaintainer@… removed
Owner: changed from macports-tickets@… to stromnov@…
Port: py-jupyter py-notebook added; py34-notebook removed
Summary: jupyter: its subcommands are versioned, they should notpy-jupyter: its subcommands are versioned, they should not

comment:3 Changed 8 years ago by akimd (Akim Demaille)

Can't we just install the tools (nbconvert, notebook, etc.) in a directory that depends on the version of the tool? Something like /opt/local/libexec/jupyter-3.4/bin/notebook etc. Then jupyter would just setup the PATH to go there first.

I don't think it matters to exhibit jupyter-notebook to the user jupyter notebook (no dash) suffices. Like what git does.

comment:4 Changed 8 years ago by stromnov (Andrey Stromnov)

All executables are already installed at /opt/local/Library/Frameworks/Python.framework/Versions/X.Y/bin without any suffices.

So you can freely use native names:

PATH="/opt/local/Library/Frameworks/Python.framework/Versions/3.4/bin:$PATH" jupyter

and

PATH="/opt/local/Library/Frameworks/Python.framework/Versions/3.4/bin:$PATH" jupyter notebook

comment:5 Changed 8 years ago by akimd (Akim Demaille)

Hi!

That's nice, but that's not enough. It should really just work out of the box. I have used port select to use jupyter-3.4, so all the suite of jupyter should be available. If git were to be installed with different versions, no-one would ever run git branch-1.7, git clone-1.7, yet git-1.7 branch etc. would be acceptable.

I believe that jupyter-3.4 should setup the PATH so that what you describe works.

comment:6 Changed 8 years ago by akimd (Akim Demaille)

I have used port select to use jupyter-3.4

Well, no, I did that for ipython, but not for jupyter. However, I can't find a jupyter_select package.

comment:7 Changed 7 years ago by stevecheckoway (Stephen Checkoway)

Cc: stevecheckoway added

comment:8 Changed 7 years ago by ssllmit (ss)

cc me

This is an issue that I've been hoping would be resolved through the standard port select feature for a while now.

comment:9 Changed 6 years ago by Schamschula (Marius Schamschula)

Cc: Schamschula added

comment:10 Changed 6 years ago by chrstphrchvz (Christopher Chavez)

Cc: chrstphrchvz added

comment:11 Changed 6 years ago by jjstickel (Jonathan Stickel)

Cc: jjstickel added

comment:12 Changed 6 years ago by jjstickel (Jonathan Stickel)

The subcommands no longer use the version number; at least this works for me now:

$ jupyter-3.6 notebook

Apparently, still no jupyter_select, though.

comment:13 Changed 5 years ago by chrstphrchvz (Christopher Chavez)

I believe this issue prevents MacPorts' Jupyter from being easily used with the Python extension for Visual Studio Code. The extension tries to start Jupyter notebook using /path/to/python -m jupyter notebook. I can configure it to use MacPorts' Python, but it's not enough for it to work:

$ /opt/local/bin/python3.7 -m jupyter notebook
Error executing Jupyter command 'notebook': [Errno 2] No such file or directory

I'm not sure yet if starting jupyter-notebook-3.7 manually and then giving the extension the URL is a workaround. Alternatively I can ask vscode-python if they can accommodate specifying a custom command (jupyter notebook-3.7) rather than a hardcoded one.

comment:14 Changed 5 years ago by essandess (Steve Smith)

In 90771f7ae6543e4fc98467ff4ab5f91cc774597f/macports-ports (master):

ihaskell: Submission of a Haskell kernel for Jupyter

  • Uses port:stack for build
  • Uses Paths_ihaskell.hs for correct ${prefix} of Cabal data-files path

Related: https://github.com/haskell/cabal/issues/6234
Related: https://github.com/commercialhaskell/stack/issues/5026
Related: #50608

Note: See TracTickets for help on using tickets.