#50608: jupyter: its subcommands are versioned, they should not ------------------------------+-------------------------------- Reporter: akim.demaille@… | Owner: macports-tickets@… Type: defect | Status: new Priority: Normal | Milestone: Component: ports | Version: 2.3.4 Resolution: | Keywords: Port: py34-notebook | ------------------------------+-------------------------------- Comment (by 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. -- Ticket URL: <https://trac.macports.org/ticket/50608#comment:1> MacPorts <https://www.macports.org/> Ports system for OS X

#50608: py-jupyter: its subcommands are versioned, they should not --------------------------------------+------------------------ Reporter: akim.demaille@… | Owner: stromnov@… Type: defect | Status: new Priority: Normal | Milestone: Component: ports | Version: 2.3.4 Resolution: | Keywords: Port: py-jupyter, py-notebook | --------------------------------------+------------------------ Comment (by 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. -- Ticket URL: <https://trac.macports.org/ticket/50608#comment:3> MacPorts <https://www.macports.org/> Ports system for OS X

#50608: py-jupyter: its subcommands are versioned, they should not --------------------------------------+------------------------ Reporter: akim.demaille@… | Owner: stromnov@… Type: defect | Status: new Priority: Normal | Milestone: Component: ports | Version: 2.3.4 Resolution: | Keywords: Port: py-jupyter, py-notebook | --------------------------------------+------------------------ Comment (by 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. -- Ticket URL: <https://trac.macports.org/ticket/50608#comment:5> MacPorts <https://www.macports.org/> Ports system for OS X