[MacPorts] #50608: jupyter: its subcommands are versioned, they should not

MacPorts noreply at macports.org
Fri Feb 12 06:56:16 PST 2016


#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


More information about the macports-tickets mailing list