Skip to content

Add pyproject.toml file to specify the requirements to build PyYaml#400

Open
aidandj wants to merge 1 commit into
yaml:mainfrom
aidandj:pyproject
Open

Add pyproject.toml file to specify the requirements to build PyYaml#400
aidandj wants to merge 1 commit into
yaml:mainfrom
aidandj:pyproject

Conversation

@aidandj
Copy link
Copy Markdown

@aidandj aidandj commented May 13, 2020

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.

@perlpunk
Copy link
Copy Markdown
Member

Travis CI is currently failing because of the libyaml tests. Working on that in #404

@perlpunk
Copy link
Copy Markdown
Member

@artificial-aidan I fixed the libyaml tests with this: yaml/libyaml@a718a89
Retriggered the tests

@nitzmahone
Copy link
Copy Markdown
Member

nitzmahone commented May 21, 2020

@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.

@aidandj
Copy link
Copy Markdown
Author

aidandj commented May 21, 2020

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.

@nitzmahone
Copy link
Copy Markdown
Member

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).

@kitterma
Copy link
Copy Markdown

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants