Hacker News new | ask | show | jobs
by dalke 1951 days ago
> "as we've always been"

To reuse a phrase from the native-Spanish-speaking Americans of the Southwest, whose family moved there in the 1700s or earlier, "I didn't cross the border, the border crossed me."

In the late 1990s, when I started with Python, writing Python C extensions was definitely not off the beaten path. I remember reading the design discussion, and I think I contributed some input too. I probably knew the original developers from going to Python conferences.

I know that at 20+ years old it's also long in the tooth. There's certainly features I would like that just aren't going to happen with it, like being able to emit a Makefile that I can use during development for incremental rebuilds, instead of taking 10 seconds to compile.

And distutils isn't going away for another couple of years, so I can plan time to migrate.

But I don't have an inkling of what that migration path might be, and can find no mention that the current set of developers are even aware of this issue. (Not that I've looked for more than a few hours.)

BTW, is "setup.cfg" dead and forgotten now?
1 comments
BerislavLopac 1951 days ago
> distutils isn't going away for another couple of years, so I can plan time to migrate

I'd say it's not going away for as long as setuptools will be based on it.

> BTW, is "setup.cfg" dead and forgotten now?

Basically, the same answer as above: setup.cfg was (as I understand) an internal solution to declarative build configuration (originally introduced in now-discontinued distutils2). It is basically precursor to pyproject.toml, and it was actually one of the alternatives proposed in PEP 518 [0] (but was declined because it depends on Python's configparser, making it not much more universal than setup.py).

[0] https://www.python.org/dev/peps/pep-0518/

link
dalke 1951 days ago
The setuptools documentation says: "All python package must provide a pyproject.toml and specify the backend (build system) it wants to use."

What is the build system which indicates the heritage build system?

Oh, I see. That documentation conflicts with PEP 517, which states:

> If the pyproject.toml file is absent, or the build-backend key is missing, the source tree is not using this specification, and tools should revert to the legacy behaviour of running setup.py (either directly, or by implicitly invoking the setuptools.build_meta:__legacy__ backend).

I find this whole thing frustrating. Eg, the setuptools documentation mentions 'setuptools.Extension' in passing, while talking about Cython, but does not document how Extension() is used??

Regarding setup.cfg, https://setuptools.readthedocs.io/en/latest/userguide/declar... seems to say that there is still a setup.cfg but it "has limited compatibility with the distutils2-like setup.cfg sections used by the pbr and d2to1 packages".

So far I haven't found a PEP 517-compatible build system which handles C-extensions. The closest is "bento", mentioned in the PEP, but it hasn't been updated since August 2014.

link
BerislavLopac 1950 days ago
Yes, I perfectly understand your frustration... :(

Again, I suggest you to try asking for advice on the Python discussion boards and the packaging problems tracker...

link