| fungi | overloading pbr.json with it probably doesn't make a lot of sense unless we extend pbr to intentionally store and retrieve that additional information, but adding a new metadata file isn't that big of a deal | 00:00 |
|---|---|---|
| clarkb | though extending PBR to store change data might not be the worst thing | 00:00 |
| fungi | yeah, that does also seem like a reasonable route | 00:00 |
| clarkb | potentially useful outside of zuul | 00:00 |
| fungi | yep | 00:05 |
| fungi | can't say i didn't see it coming, but setuptools 58.3.0 (released yesterday) now raises this deprecation warning: "setuptools._deprecation_warning.SetuptoolsDeprecationWarning: setup_requires is deprecated. Supply build dependencies using PEP 517 pyproject.toml build-requires." | 12:59 |
| fungi | can't filter on the exception itself in PYTHONWARNINGS due to it being private (that's annoying) but at least it can match on the message string | 13:25 |
| fungi | if we want to avoid committing pyproject.toml files to every python repo, we're going to need some sort of wrapper to generate them on the fly before calling something like build | 14:25 |
| fungi | e.g. a `pbr build` subcommand maybe | 14:26 |
| fungi | or `python3 -m pbr.build` | 14:27 |
| fungi | okay, so there's actually three new warnings i have to filter to get things working with setuptools 58.3.0... | 14:31 |
| fungi | ignore:setup.py install is deprecated. Use build and pip and other standards-based tools., ignore:setup_requires is deprecated. Supply build dependencies using PEP 517 pyproject.toml build-requires., ignore:easy_install command is deprecated. Use build and pip and other standards-based tools. | 14:31 |
| fungi | this is going to become a major problem as soon as any of those is removed because projects too old to provide abi3 manylinux wheels are just going to cease to be installable with newer setuptools | 14:34 |
| fungi | if we thought the fallout from the use_2to3 removal was bad... | 14:34 |
| fungi | though i expect this is going to be the one to bite us next: https://github.com/pypa/setuptools/pull/2822 | 14:37 |
| fungi | in theory that's going to happen in setuptools 59, though no idea when it's planned for release | 14:38 |
| fungi | but we should still keep a close eye on https://github.com/pypa/setuptools/issues/2823 too | 14:38 |
| Clark[m] | Probably the best thing is make https://review.opendev.org/c/openstack/pbr/+/797898 landable and then use the modern system for selecting the package tool | 14:41 |
| fungi | latest yamllint is still raising the LegacyVersion warning, looks like | 14:42 |
| Clark[m] | And ya hope not too many old projects explode (but know that many will) | 14:42 |
| fungi | huh, this yamllint build warning should have been fixed two releases ago from what i can see. now to figure out why pip would be trying to build an older version | 14:46 |
| fungi | ugh, so my quest to track down legacyversion deprecation warnings in my code eventually led me to https://github.com/pypa/packaging/pull/407 | 14:56 |
| fungi | i find it surprising that features would be deprecated while still in use by the other fundamental packaging libraries, like... packaging | 14:57 |
| fungi | basically pip installing anything in a python3.10 venv raises "pip._vendor.packaging.version.InvalidVersion: Invalid version: 'pip'" | 14:59 |
| fungi | and so with PYTHONWARNINGS=error that triggers a fallback path into pkg_resources, looping back to packaging, raising the legacyversion warning | 15:00 |
| fungi | and for reasons i still don't understand, pip triggers parsing metadata for yamllint 1.25.0 even though 1.26.3 installs fine | 15:10 |
| fungi | yeah, this seems like a fatal flaw in pip's dep solver | 15:13 |
| fungi | from what i can tell it fetches the entire list of yamllint versions *and* parses all their package metadata, even versions which aren't the one you've insisted on, hands them off to the vendored version of the packaging module, which then chokes on an InvalidSpecifier exception, the exception handling for which round-trips back through to instantiate a LegacySpecifier() object which then | 15:15 |
| fungi | raises the LegacyVersion DeprecationWarning | 15:15 |
| fungi | probably the solution is for yamllint to "hide" its 1.25.0, 1.26.0 and 1.26.1 releases on pypi, since they contain version specifiers which packaging considers invalid | 15:17 |
| fungi | would probably also be a good idea for pip to defer parsing as much metadata as possible prior to creating an initial list of candidate versions | 15:18 |
| fungi | since `pip install yamllint==1.26.3` still breaks when packaging is asked to (unnecessarily) parse metadata for 1.25.0 | 15:19 |
| fungi | thinking through it, i expect once packaging drops its LegacySpecifier class as a fallback, it will just error trying to parse the broken metadata for those versions and pip will skip them, which will make them uninstallable but at least it will no longer raise deprecationwarnings in its exception handling (and so proceed normally even with PYTHONWARNINGS=error) | 15:30 |
| fungi | also for those wondering what broken package metadata i'm talking about in yamllint, it's what was corrected in https://github.com/adrienverge/yamllint/commit/4374490 | 15:34 |
| *** dpawlik6 is now known as dpawlik | 15:55 | |
| fungi | also pyparsing 3.0.0 was just now released, causing https://github.com/pyparsing/pyparsing/issues/111 to resurface | 18:19 |
Generated by irclog2html.py 2.17.2 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!