pyyaml
pyyaml copied to clipboard
yaml
Add pyproject.toml file to specify the requirements to build PyYaml
Using PEP-518 we can specify that setuptools and wheel be installed. This fixes an issue that can occur if someone has a python environment without wheel.
Travis CI is currently failing because of the libyaml tests. Working on that in #404
@artificial-aidan I fixed the libyaml tests with this: https://github.com/yaml/libyaml/commit/a718a893542e7cf9ab8862d2ef8c43d33644cc8d Retriggered the tests
@artificial-aidan in our tests for this problem, it seems to be specific to Debian/Ubuntu builds that do ... interesting things by (partially) removing the vendored wheel bits from pip in ways that don't work with virtualenv/venv. Does one of those situations apply to what you're talking about? If so, IIRC manually installing wheel doesn't help either- it's just plain broken, depending on how you created the venv. They've intermittently fixed and re-broken it in different ways across different Ubuntu releases, where the pip code that tries to detect if wheel is present "sees" the system version of wheel in dist-packages, but isn't able to call it, resulting in the various error/warning messages about bdist_wheel not being a valid command.
It was also only a problem for Ubuntu on my end. OSX worked fine. I'm not sure if manually installing wheel worked or not. Because the install succeeds even though there is a warning, the next time around, I don't get a message.
Regardless, if that's the case you're trying to fix here, pyproject.toml declaring wheel as a dep won't fix the Ubuntu issue. Depending on how you look at it, it's either a pip bug or an Ubuntu/Debian bug (because they do weird things to pip when they package it that break its wheel detection/fallback code).
FWIW, the unvendoring we do in Debian is supported by pip upstream. Both pip and virtualenv have recently been updated in Debian Unstable/Testing to the current upstream versions and the packaging significantly modernized. You don't say what Debian release you are using, but for Unstable/Testing it should all work now.
For Debian Stable, the virtualenv version is too old to support manylinux wheels, so it probably won't make a difference either way there.
There was a wheel detection issue that caused virtualenv to think wheel was available when it's not, but when it's not actually present, while the bdist_wheel command fails (that would be the warning you mention), the fallback to a regular bdist generally succeeds (which is why there's no warning the second time, because the requirement is already satisfied). In any case, that too is now fixed in Unstable/Testing.
