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

Release xeus-python on PyPI #181

Open
afshin opened this issue Nov 29, 2019 · 20 comments
Open

Release xeus-python on PyPI #181

afshin opened this issue Nov 29, 2019 · 20 comments

Comments

@afshin
Copy link
Member

afshin commented Nov 29, 2019

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.

@SylvainCorlay
Copy link
Member

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.

@SylvainCorlay
Copy link
Member

We are looking into multibuild and scikit-build at the moment.

cc @jcfr @thewtex

@jcfr
Copy link

jcfr commented Dec 4, 2019

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

@jcfr
Copy link

jcfr commented Dec 4, 2019

Do you already have a wip branch pushed somewhere ?

@SylvainCorlay
Copy link
Member

SylvainCorlay commented Dec 4, 2019

No, I am reading up on scikit-build, because there are quite a few dependencies.

  • For xeus core, OpenSSL and zeromq both 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...

@SylvainCorlay
Copy link
Member

@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.

@thewtex
Copy link

thewtex commented Dec 4, 2019

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.

@SylvainCorlay
Copy link
Member

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.

@thewtex
Copy link

thewtex commented Dec 4, 2019

de-pressing

😆 @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.

@SylvainCorlay
Copy link
Member

SylvainCorlay commented Dec 12, 2019

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
Copy link

thewtex commented Dec 15, 2019

@thewtex do you have an example of a package that would be doing this?

I am going to try this with ITK :-).

@SylvainCorlay
Copy link
Member

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.

@thewtex
Copy link

thewtex commented Mar 30, 2020

@SylvainCorlay awesome!

@SylvainCorlay
Copy link
Member

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.

@afshin
Copy link
Member Author

afshin commented Apr 17, 2020

I got a little bit emojinal there, but it is warranted.

@sknigh
Copy link

sknigh commented Jul 1, 2020

@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 (jupyterlab/debugger#479 (comment)).

@SylvainCorlay
Copy link
Member

@sknigh I have released 0.8.3 on pypi.

@dlukes
Copy link

dlukes commented Feb 17, 2021

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) :)

@martinRenou
Copy link
Member

I will build the wheel and publish it 👍🏼

@martinRenou
Copy link
Member

xeus-python 0.11.1 is on PyPi

DerThorsten pushed a commit to DerThorsten/xeus-python that referenced this issue Nov 7, 2023
* Add more skip-if-exists

* remove wheel config

* fix typo

* Remove before-build-python hook

* Re-add `wasm` to files

* Fix build:prod script

* Delete MANIFEST.in

* edit config

* include static directory explicitely ?

* narrow down gitignore

* fix typo
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

No branches or pull requests

7 participants