Publish sdist and bdist wheel

[groodt]

The benefits of wheels are well documented. See: https://pythonwheels.com/
This package is pure Python and publishing it as both source and as a wheel is simple.

[groodt]

@edschofield Is this of interest at all?

[groodt]

@jmadler Is this of interest at all?

This package is now the first package that is displayed on https://pythonwheels.com/ that is not distributed as a Wheel.

[sfdye]

Hi maintainers, I can help with this if you are okay, just need the necessary permission

[jmadler]

According to this documentation, wheels are built specified at the Python major version level of granularity (Py2, Py3). However, we need to build packages that'd be installed based on a major.minor.micro version scheme.

Is there a way to achieve your objective of publishing binary packages at the micro-level of granularity?

[groodt]

I believe the compatibility for Python built distributions is specified in PEP 425

It supports specifying compatibility down to the minor version e.g.
py33-none-any

Does future truly install differently based on the .micro version?

[jmadler]

Not based on micro, no, but minor version certainly. It's possible future changes to Python's APIs at the micro-release level may require us to do so, however, and moving off of our current package format removes that capability. We do some runtime checks at the micro level, but I worry about compile-time optimizing these version checks, as the file would be unusable on versions other than the install version. Do wheels provide any sort of safeguard around t hat?

…

On Sun, Jun 7, 2020 at 7:16 PM Greg Roodt ***@***.***> wrote: I believe the compatibility for Python built distributions is specified in PEP 425 <https://www.python.org/dev/peps/pep-0425/> It supports specifying compatibility down to the minor version e.g. py33-none-any Does future truly install differently based on the .micro version? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#536 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AADKHVTRJFQTQCYFLSK7NMLRVRCY3ANCNFSM4J6FJ7EA> .

[groodt]

Not based on micro, no, but minor version certainly.

Ok, Wheels already support this.

It's possible future changes to Python's APIs at the micro-release level may require us to do so, however, and moving off of our current package format removes that capability.

Micro version changes in Python are for bug fixes only https://devguide.python.org/devcycle/#maintenance-branches

We do some runtime checks at the micro level, but I worry about compile-time optimizing these version checks, as the file would be unusable on versions other than the install version. Do wheels provide any sort of safeguard around t hat?

Wheels do not contain any .pyc files. The .py files are compiled to .pyc when the Wheel is installed, so there would be no issue.

A Wheel is installed into a particular versioned Python environment (or virtual env). Any hypothetical micro version runtime checks in future can still happen at import time and the result cached which should address any optimization concerns.

[kgaughan]

Never mind. According to #400, there are internal design issues in future that prevent it from being marked as universal. I'm leaving my original comment present, as it might give some context for why this PR is important. Apologies.

---

There's an issue with this PR that needs fixing. Due to the nature of future, it should be marked as a universal wheel. This can be fixed pretty easily by adding the following to setup.cfg:

[bdist_wheel]
universal = 1

I'd be very, very interested in getting this PR fixed and merged as it would ease cross-platform AWS lambda development for those of us with some binary dependencies that necessitate the use of wheels. As future only has a source distribution, there's no way to both supply the flags for the target platform, which is needed if you have binary dependencies.

[sfdye]

@kgaughan Because future uses 2to3 so it can't be built as a universal wheel:

See: https://packaging.python.org/guides/distributing-packages-using-setuptools/#universal-wheels

[sfdye]

Also I am afraid this PR is not enough to get wheels built automatically. I will try to build some wheels manually and upload to PyPI to test it out before we can use CI to build wheels for us.

[sfdye]

I've uploaded py27 and py36 pure python wheels for v0.18.0:
https://pypi.org/project/future/0.18.0/#files

$ pip install 'future==0.18.0'
Collecting future==0.18.0
  Downloading future-0.18.0-cp36-none-any.whl (490 kB)
     |████████████████████████████████| 490 kB 1.9 MB/s
Installing collected packages: future
  Attempting uninstall: future
    Found existing installation: future 0.18.1
    Uninstalling future-0.18.1:
      Successfully uninstalled future-0.18.1
Successfully installed future-0.18.0

Please have a try and let me know if it works

[kgaughan]

@sfdye Ah, that's unfortunate. Nice to see the py36 wheel though! Thanks for your work.

[kgaughan]

It just occurred to me that you might want to take a look at https://github.com/joerick/cibuildwheel as it's pretty widely used. That could help with getting the wheels built automatically, and works with a good number of CI services.

[sfdye]

I am aware of that

[groodt]

I see this PR was closed, but I don't see any wheels being published to PyPI? Was this closed in error?