bjoern icon indicating copy to clipboard operation
bjoern copied to clipboard

Wheel support?

Open Varbin opened this issue 6 years ago • 22 comments

Having wheels on PyPi could make installation a lot faster and may also solve the "library headers are required for installation"-problem.

By the way, nice work!

Varbin avatar Jan 24 '18 19:01 Varbin

Good idea. Not sure what this means for release management though? Is there some wheel-as-a-service thing so I don't need to have Windows Mac and Linux?

jonashaag avatar Jan 25 '18 07:01 jonashaag

Some CI services could be used. On Travis OS X containers can be used (but I have no experience with them) and AppVeyor (See https://packaging.python.org/guides/supporting-windows-using-appveyor/) makes it possible to build on Windows - still this all has to be set up.

For Linux an "manylinux" wheel would be great, it is possible to also use them on travis (example project: https://github.com/pypa/python-manylinux-demo).

Varbin avatar Jan 25 '18 07:01 Varbin

Ok, I'm happy to incorporate this into the release process as long as it means I don't have to install Linux or Windows. Even better if this could be done completely on CI or some trustworthy third party service.

jonashaag avatar Jan 25 '18 08:01 jonashaag

(Docker is fine as well)

jonashaag avatar Jan 25 '18 08:01 jonashaag

@jonashaag The manylinux wheel creation is done with Docker.

Varbin avatar Jan 25 '18 16:01 Varbin

I see; I'll have a look

jonashaag avatar Jan 25 '18 20:01 jonashaag

Looks good but seems to be a bit of work. Feel free to contribute a working PR :)

jonashaag avatar Jan 29 '18 10:01 jonashaag

As Continuous Integration could also run a test suite, would you mind if I convert some of the present tests into some independently running automated tests? So before building wheels, it will be tested if nothing broke.

Varbin avatar Jan 29 '18 15:01 Varbin

Before doing so, I would like to finish #122/#123 first.

Varbin avatar Jan 29 '18 15:01 Varbin

As Continuous Integration could also run a test suite, would you mind if I convert some of the present tests into some independently running automated tests? So before building wheels, it will be tested if nothing broke.

That would be absolutely awesome. See also #52. I never got around to doing it.

jonashaag avatar Jan 29 '18 15:01 jonashaag

I would like to say that I find this PR quite interesting. Based upon corporate constraints, I have to develop on a Windows machine, even though I deploy to Linux. It would be nice to be able to have bjoern run on my development environment.

Jitsusama avatar Feb 05 '18 14:02 Jitsusama

I have binary wheels built for several Debian and Ubuntu releases here https://github.com/dgilman/bjoern/releases

dgilman avatar Jan 08 '19 05:01 dgilman

Does the wheel embed libev or do you still need to install libev4 ? does manylinux requires plateforme to ship libev ?

bersace avatar Mar 29 '19 08:03 bersace

Here's my humble suggestion: a Travis job configuration that builds fat Linux/MacOS wheels with libev included, installs them and runs unit tests, with additional releasing on tag push. Examples:

This is how the release would look like (a fake 3.0.3 in this example):

Linux wheels are being built in the pypa/manylinux1 containers, so nothing special here to report. Regarding MacOS wheels: not sure what versions/platforms are relevant - @jonashaag do you have any ideas? For now, I only included the cp27/36/37 for the macosx_10_9_x86_64 platform; 3.4 is unsupported and IIRC 3.5 has issues with the OpenSSL version linked against on MacOS (AFAIK it's still the 0.9.8), so not sure whether someone still uses 3.5 on MacOS.

No fat wheels for Windows since I couldn't get past compiling http_parser with MSVC (e.g. build on Appveyor), so dropped it for now.

I also started to port the scripts from the tests/ directory to unit tests (sample tests already executed in jobs), will drop some thoughts in #52. In preparation for that, I configured collecting code coverage and uploading it to codecov: here's what it can look like in the end.

hoefling avatar Jul 27 '19 23:07 hoefling

Actually, releasing one plateform at a time may help make a step further.

bersace avatar Aug 27 '19 09:08 bersace

Just a note, we should ship a variant with statd enabled. I thinks of another wheel named bjoern-statd.

bersace avatar Jan 13 '20 09:01 bersace

@jonashaag what is the release process as of now ? Do you push manually artefacts to PyPI ?

bersace avatar Jan 13 '20 09:01 bersace

Ok, I found make upload. https://github.com/jonashaag/bjoern/blob/master/Makefile#L116-L117 Is it relevant ?

bersace avatar Jan 13 '20 09:01 bersace

Yes that's what I'm using. And that's the entire release process for now.

I'm happy to change to any other release process ;)

jonashaag avatar Jan 13 '20 11:01 jonashaag

Any update on wheels ? I would like to not have to install libev using apt for pip installing bjoern. Thanks.

pythonmobile avatar May 15 '20 22:05 pythonmobile

For what it's worth, I wanted to build Bjoern wheels for an internal use-case so I wrote a Dockerfile to do it:

FROM quay.io/pypa/manylinux2014_x86_64
RUN yum install -y gcc libev-devel \
    && /opt/python/cp38-cp38/bin/pip3.8 wheel bjoern==3.1.0 \
    && auditwheel repair /bjoern-3.1.0-cp38-cp38-linux_x86_64.whl

This generates /wheelhouse/bjoern-3.1.0-cp38-cp38-manylinux2014_x86_64.whl which can then be installed on a system which does not have libev installed.

danielsamuels avatar Nov 18 '20 15:11 danielsamuels

#178 added plumbing for wheels on Linux. But @jonashaag didn't published wheels yet on PyPI. Today, I also had a look at https://cibuildwheel.readthedocs.io/en/stable/setup/#github-actions which may improve the situation.

bersace avatar Dec 10 '21 07:12 bersace