The parse_wheel_filename() function currently returns a 4-tuple of (name, version, build, tags), corresponding to the current components of wheel filename. However, PEP 825 proposes adding another optional component, the variant label. This raised the question how to update the function for that standard.
My personal preference would be to soft-deprecate it, and introduce a new function. In the simplest case, it would be just literally parse_wheel_filename2() that adds another tuple element; though I was told that there's already been talk of replacing the function, so perhaps we should consider better ideas.
Either way, I think a replacement is a good strategy because it ensures that existing tools aren't broken in any way. They will continue working as expected on non-variant wheels, and raise an exception (which should be preferable to misbehaving) on new variant wheels. If tools need to support variant wheels, they switch to the new API and cover the necessary new component at the same time.
The
parse_wheel_filename()function currently returns a 4-tuple of(name, version, build, tags), corresponding to the current components of wheel filename. However, PEP 825 proposes adding another optional component, the variant label. This raised the question how to update the function for that standard.My personal preference would be to soft-deprecate it, and introduce a new function. In the simplest case, it would be just literally
parse_wheel_filename2()that adds another tuple element; though I was told that there's already been talk of replacing the function, so perhaps we should consider better ideas.Either way, I think a replacement is a good strategy because it ensures that existing tools aren't broken in any way. They will continue working as expected on non-variant wheels, and raise an exception (which should be preferable to misbehaving) on new variant wheels. If tools need to support variant wheels, they switch to the new API and cover the necessary new component at the same time.