-
-
Notifications
You must be signed in to change notification settings - Fork 377
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
install kernelspec in wheels #223
Conversation
- wheel kernelspec relies on PATH env to find python (this should be okay when installed to sys.prefix) - can't use universal wheels anymore, since Python version is in kernelspec name and display name
65d8c50
to
ec7320e
Compare
I'm not convinced by relying on PATH - that assumes that people always activate a virtualenv rather than launching scripts inside it directly. |
We could handle the executable |
instead of setup_requires
rely on install from wheel
and skip travis-wheels, which is obsolete now that manylinux wheels are a thing
rather than just Python 2.7
7a2c55e
to
f7a116c
Compare
rather than bdist_wheel still builds and installs with wheel
Well, crap. I swear I didn't click the merge button, but GitHub interpreted a click in the comment area as a click of the merge button (not sure if it's GitHub's or my browser's fault). I can revert and re-issue the PR if you want, or we can continue to review this PR and I'll open a new one for any changes that should result. I cleaned up travis.yml a bit to do a 'regular' install rather than an editable one for testing. |
Let's carry on without reverting. |
Nice! |
It would be ideal to get a hardcoded path at install time (pypa/pip#4032), but for envs this should do until that becomes possible.
After this, it should be a lot harder for the native kernelspec to not be installed, which would be ideal. Plus, uninstalling ipykernel will also uninstall the kernelspec.