Saturday, 2021-10-23

fungioverloading 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 deal00:00
clarkbthough extending PBR to store change data might not be the worst thing00:00
fungiyeah, that does also seem like a reasonable route00:00
clarkbpotentially useful outside of zuul00:00
fungican'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
fungican'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 string13:25
fungiif 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 build14:25
fungie.g. a `pbr build` subcommand maybe14:26
fungior `python3 -m`14:27
fungiokay, so there's actually three new warnings i have to filter to get things working with setuptools 58.3.0...14:31 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
fungithis 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 setuptools14:34
fungiif we thought the fallout from the use_2to3 removal was bad...14:34
fungithough i expect this is going to be the one to bite us next:
fungiin theory that's going to happen in setuptools 59, though no idea when it's planned for release14:38
fungibut we should still keep a close eye on too14:38
Clark[m]Probably the best thing is make landable and then use the modern system for selecting the package tool14:41
fungilatest yamllint is still raising the LegacyVersion warning, looks like14:42
Clark[m]And ya hope not too many old projects explode (but know that many will)14:42
fungihuh, 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 version14:46
fungiugh, so my quest to track down legacyversion deprecation warnings in my code eventually led me to
fungii find it surprising that features would be deprecated while still in use by the other fundamental packaging libraries, like... packaging14:57
fungibasically pip installing anything in a python3.10 venv raises "pip._vendor.packaging.version.InvalidVersion: Invalid version: 'pip'"14:59
fungiand so with PYTHONWARNINGS=error that triggers a fallback path into pkg_resources, looping back to packaging, raising the legacyversion warning15:00
fungiand for reasons i still don't understand, pip triggers parsing metadata for yamllint 1.25.0 even though 1.26.3 installs fine15:10
fungiyeah, this seems like a fatal flaw in pip's dep solver15:13
fungifrom 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 then15:15
fungiraises the LegacyVersion DeprecationWarning15:15
fungiprobably 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 invalid15:17
fungiwould probably also be a good idea for pip to defer parsing as much metadata as possible prior to creating an initial list of candidate versions15:18
fungisince `pip install yamllint==1.26.3` still breaks when packaging is asked to (unnecessarily) parse metadata for 1.25.015:19
fungithinking 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
fungialso for those wondering what broken package metadata i'm talking about in yamllint, it's what was corrected in
*** dpawlik6 is now known as dpawlik15:55
fungialso pyparsing 3.0.0 was just now released, causing to resurface18:19

Generated by 2.17.2 by Marius Gedminas - find it at!