Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Include minor version in KERNEL_SPEC #301

Closed
wants to merge 1 commit into from
Closed

Include minor version in KERNEL_SPEC #301

wants to merge 1 commit into from

Conversation

neirbowj
Copy link

This change allows concurrent installation of ipykernel under
multiple minor versions of the same major version because of files
that are installed to share/jupyter/kernels/${KERNEL_NAME}.

This change allows concurrent installation of ipykernel under
multiple minor versions of the same major version because of files
that are installed to share/jupyter/kernels/${KERNEL_NAME}.
@neirbowj
Copy link
Author

This is to facilitate FreeBSD support for concurrent installation per available minor version. See bug 225518 for the downstream patch.

@minrk
Copy link
Member

minrk commented Feb 8, 2018

I think we should be thinking about going the opposite direction, and use python with no version. Then the same 'python' kernelspec works correctly for the current Python, regardless of env.

Changing python3 to python3.6 (or python for that matter) as is done here, though, would be a breaking change for all existing Python notebooks in the world, so we need to be extremely careful about doing this, and only add pythonX.Y, instead of replacing pythonX, if we decide this is desirable.

FreeBSD packages are welcome to install pythonX.Y kernelspecs if they like. This is doable now by running ipython kernelspec install --name pythonX.Y --prefix $PREFIX as part of the package build.

@neirbowj
Copy link
Author

neirbowj commented Feb 8, 2018

Thank you for this feedback. I will investigate whether the kernelspec installation capability is a viable alternative for the problem I'm trying to solve. What I hope is that ipykernel could gain support for a layer if indirection comparable to that defined by PEP 394.

The FreeBSD ports tree already supports this for the python family of ports by layering lang/python and lang/pythonX that only install suitable symlinks on top of lang/pythonXY. There is lower granularity support for concurrently installing a given python-based port that installs an executable script that renames each executable that would otherwise collide with a "-X.Y" suffix and then installs bare symlinks to the instance that uses the system default X.Y.

@minrk
Copy link
Member

minrk commented Feb 12, 2018

You may be interested in jupyter/jupyter_client#308 which adjusts how kernels are discovered in a way that's potentially relevant.

@ivanov
Copy link
Member

ivanov commented May 15, 2021

Hey there @neirbowj , I'm going through old issues and it seems to me that it makes sense to close this one. Thanks for pitching in for ipykernel both here and in the FreeBSD ports tree.

Thanks everyone and happy hacking! :bowtie:

@ivanov ivanov closed this May 15, 2021
@ivanov ivanov added this to the no action milestone May 15, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants