Upload to PyPi about adafruit_python_dht

[brennen]

Current release is live on PyPI, issues here mostly appear to have been addressed, at least as far as publishing a source distribution.

[spuder]

+1

[Cabalist]

Yes please!

[QuentinAndre]

+1 ! For people working with virtualenv, this would be really convenient.

[tdicola]

Great issue and apologies it's been a while to be reviewed. So the tricky thing here is that pypi has no concept of platforms like the Raspberry Pi, BeagleBone Black, etc.--as far as PyPi is concerned these are all Linux platforms that are the same. The trouble is we need to compile specific code for each of these boards, and right now that logic lives in the setup.py when the install is run. If this is bundled up and published to PyPi using the wheel format they want everyone to use these days it won't run the setup.py and will instead the same (incorrect) compiled code across all platforms.

I'm not really familiar with the eccentricities of Python's binary & source distributions so perhaps there is a magic way to make this kind of scenario work. From what I understand more granular platform/hardware-specific binary wheels are a known limitation of python's packaging system today. If someone knows of a way feel free to suggest it--for now I'll keep this open as a reminder of it being a known issue.

[samjetski]

You can simply release it as a source distribution (sdist without bdist, no wheels). This is the baseline way to publish to PyPI. Produces a tar file which pip will download, extract and run python setup.py install on automatically.

This way it'll compile on each machine that it's installed on, which should address the cross-platform concerns. Obviously a binary distribution with wheels is preferred for speed, but if that isn't possible it won't stop you publishing on PyPI.

To test it locally: (spits out a tar.gz which you can feed to pip install)

python setup.py sdist

There is a detailed (source only) guide here.

Edit: The project will need a few small tweaks to prep it for sdist, but this fork has already done most of the work.

[bennuttall]

@samjetski

Obviously a binary distribution with wheels is preferred for speed, but if that isn't possible it won't stop you publishing on PyPI.

I've built a system to build ARM wheels (on a Pi 3) of every package on PyPI. It's done one complete sweep, and I'm going to be making sure it keeps everything up to date, and I'll build ARMv6 wheels too at some point. [done] Check it out: https://www.piwheels.org/

[samjetski]

@bennuttall: That looks great, nice project! I confess to not understanding the platform differences well, but I think part of the problem @tdicola was referring to was that although Pi3 and Beaglebone Black are both ARMv7, they require different code to address the GPIO hardware. So to create an ARMv7 bdist_wheel which can be published to PyPI, the project would need to be changed to detect the hardware platform at runtime (currently this is done at install/compile time).

If I've got this right, we'll need to stick to a source distribution on PyPI unless/until such a rewrite is done, to ensure that it still works on Beaglebone. But it should still work fine for your dedicated Pi3 pip mirror repo (since presumably people would only be pointing Raspberry Pis at it). And if you're mirroring from PyPI, then all the more reason for us to get an sdist up on PyPI.

[bennuttall]

So to create an ARMv7 bdist_wheel which can be published to PyPI

As far as I'm aware, PyPI doesn't accept ARM wheels anyway

[tedder]

The name has been stomped on; see #77.

[bennuttall]

PyPI does now allow Arm wheels to be uploaded, but Raspbian users get piwheels by default now anyway.

[bennuttall]

piwheels has Python wheels for this package too: https://www.piwheels.org/simple/Adafruit_Python_DHT/