Distribute wheels to support PEP 518 and pip 10

[sqlalchemy-bot]

Migrated issue, originally created by Ashwin Vishnu (@avmo)

We use Mako as a build dependency in fluiddyn/fluidfft. PEP 518 support would cure our setup bootstrapping problem.

However since PEP 517 is not implemented yet, adding a pyproject.toml like this:

[build-system]
# Minimum requirements for the build system to execute.
requires = [
    "setuptools", "wheel",  "numpy", "Cython",  "Mako"
]

will result in

(test-pip10) ~/s/f/fluidfft ❯❯❯ pip install -e .                                                                                                                           
Obtaining file:///home/avmo/src/fluidmeta/fluidfft
  Could not find a version that satisfies the requirement Mako (from versions: )
No matching distribution found for Mako

According to https://pip.pypa.io/en/latest/reference/pip/#pep-518-support, this is because pip 10 supports only finding wheels, not source distributions. It is too much to ask, but since mako seems like a pure python package, will it be possible to distribute a universal wheel?

Otherwise we have to wait for PEP 517 support, which can be months :)

[sqlalchemy-bot]

Michael Bayer (@zzzeek) wrote:

mako is not actively maintained. what exactly is your "setup bootstrapping problem" ? if you're looking for a higher velocity project maybe Jinja is delivering wheels and/or following all these new pip features.

[sqlalchemy-bot]

Ashwin Vishnu (@avmo) wrote:

In fluidfft we rely on mako to generate cython code, for instance https://bitbucket.org/fluiddyn/fluidfft/src/default/src_cy/template2d_mako.pxd. So this requires mako (and also numpy and cython) to be installed prior to running setup.py. It does not matter if we specify these as dependencies in setup(...) function call. This is the bootstrapping problem.

According to a pip developer for PEP 517, it might take a long time for pip to implement.

It would be nice if we can keep using mako, and we do not mind if it is not actively maintained - it works as it is now. Nor do we require a lot of advanced templates. Are wheels not possible with mako?

[sqlalchemy-bot]

Michael Bayer (@zzzeek) wrote:

Wheels were removed because we have dynamic logic to install Markupsafe, which was because Armin removed Python 2.6 support a little sooner than the rest of the world. See #249, still opened. On the Mako side, I am hesitant to get into the suggested implementations since they are complicated and I'm looking for a solution that isn't going to break the next time pip changes things around. The best solution would be to drop python 2.6 and 3.3 support, but also the argparse requirement would need to be figured out for 2.7.

[sqlalchemy-bot]

Michael Bayer (@zzzeek) wrote:

woop argparse is in 2.7, fixed that part

[sqlalchemy-bot]

Ashwin Vishnu (@avmo) wrote:

Anyways, feel free to put this on hold. We took your advice and used
Jinja as a fallback option, without changing the templates :) Thanks

[sqlalchemy-bot]

Michael Bayer (@zzzeek) wrote:

the irony that the issue Mako has with wheels were caused by Armin in the first place :)

[sqlalchemy-bot]

Ashwin Vishnu (@avmo) wrote:

It is interesting how Jinja2 keeps Python 2.6 support, when it also depends on MarkupSafe.

It is indeed painful if a lot of people are still relying on Python 2.6 support - esp. these days when libraries are starting to drop support for Python 2 altogether. And #249 was opened in 2015. I don't think people would crucify you for dropping Python 2.6 / 3.3 support. Maybe both Jinja2 and Mako should take a stand together and start deprecation :)

[sqlalchemy-bot]

Michael Bayer (@zzzeek) wrote:

then how is Jinja accomplishing all that + wheels ?

[zzzeek]

this is a dupe of #249.