Matt Davis

I think most of us are still of the opinion that the presence of a pure-Python wheel under the `pyyaml` package on PyPI causes many more problems than it solves....

Give it a few releases for breaking API/ABI changes on the native extensions and people that, eg, have the pure-Python part installed in an OS package and the native part...

Yeah, that's one of the reasons I've not tried to attack a full setuptools cutover or any more ambitious refactoring of the packaging/install stuff- we either need to kill all...

Yeah, I'm actually reasonably confident that absent any legacy concerns, we could have a nice clean modern setup experience, but that screws everyone eg, running older stock Ubuntu LTS releases...

Yeah, just getting the libyaml extension to build under Cython 3.0 is pretty straightforward, as you've shown here- our usage of Cython is fairly basic. However, changing this would break...

> A sdist that require cython is far more likely to be usable in the future than an sdist that has cythonized c-code Agreed- we quit including Cython'd outputs in...

I'd like to target some form of this work, probably along with the more dynamic discovery of libyaml @karolyi has been working on in #618 for the next non-patch PyYAML...

On the plus side, support for `setuptools` consuming PEP517/518 config settings has improved quite a bit since February- I haven't gone back to see if will cover all the things...

Can't speak for anyone else, but I don't see a significant benefit to inclusion in stdlib over the likely hassle of doing so, especially since we're now shipping libyaml-integrated wheels...

Hrm, that's definitely a weird Cython behavior I've not noticed before. Adding the future statement in the pyx shouldn't hurt anything, so if you want to open a PR with...