xeus-python
xeus-python copied to clipboard
jupyter-xeus
Release xeus-python on PyPI
Publishing xeus-python as a package that can be installed by pip opens it up to use in a wider set of venues, namely in environments where conda is unavailable.
I am looking into conda-press and opened a number of issues in the repository. Unfortunately, conda-press does not seem to be really up to the task quite yet. We need to find another approach.
We are looking into multibuild and scikit-build at the moment.
cc @jcfr @thewtex
This is exciting !
Let us know if you have any question related to scikit-build.
As a side note, here is example of project I updated to have wheels automatically uploaded after pushing a tag. See https://github.com/amueller/word_cloud
No, I am reading up on scikit-build, because there are quite a few dependencies.
- For
xeuscore,OpenSSLandzeromqboth have a runtime. I would probably need to have a solid way to get the header-only dependencies as well during the build. - For
xeus-python, we depend on Python core, xeus, and pybind11 (header-only)...
xeus core also depends on libuuid on linux, and the "Core Foundation" runtime on OS X...
@jcfr btw, I would love to pick your brain for this if you would be ok to have a quick chat.
Also, FYI, we have iterated a lot on xeus-python lately, since this is the backend to jupyterlab/debugger.
It is worth noting that scikit-build and conda-press could / should be used together -- scikit-build helps integrate the C++ / CMake build and conda-press helps package binary dependencies.
It is worth noting that scikit-build and conda-press could / should be used together -- scikit-build helps integrate the C++ / CMake build and conda-press helps package binary dependencies.
What is de-pressing is that conda-press installs binary stuff under site-packages which breaks any conda package that is linked with libpython because the relative path is not the same as in the pure conda case.
So conda-press in its current form may not be the right tool (quite yet). Since we have a pressing need for a PyPI package I am looking at other means to do this.
de-pressing
:laughing: @scopatz -- @SylvainCorlay should get an honorary badge for this one!
conda package that is linked with libpython
If using CMake / scikit-build, this can be avoided on macOS and Linux by weak linking with targetLinkLibrariesWithDynamicLookup.
It is worth noting that scikit-build and conda-press could / should be used together -- scikit-build helps integrate the C++ / CMake build and conda-press helps package binary dependencies.
@thewtex do you have an example of a package that would be doing this?
I am mostly concerned with binary dependencies that are not cmake-based, that is zeromq and OpenSSL. All the rest should be simpler...
@thewtex do you have an example of a package that would be doing this?
I am going to try this with ITK :-).
For reference, we now have an experimental wheel on PyPI for linux only.
We already build functional wheels on Windows and OS X but are not uploading them quite yet.
For reference 0.7.1 is now on PyPI and works with user installs and virtual environments.
I will be uploading windows and OS X wheels later on.
@SylvainCorlay Would it be possible to update the xeus archive on PyPI? pip is a hard requirement in my use case and 7.1 is too old for some tools (https://github.com/jupyterlab/debugger/issues/479#issuecomment-651864058).
Just checking whether there are plans for a new release including PyPI wheels incorporating #400 in the coming weeks, or whether I should set aside some time to figure out how to install from source to try out this major milestone (can't use conda) :)
