How to handle legacy specifiers?

[dstufft]

From setuptools issue.

Currently if someone has a legacy specifier anywhere in their dependency chain it will raise a InvalidSpecifier exception. This is fine if you want strict adherence to PEP 440, however it doesn't help much if you have existing specifiers anywhere.

The question is, how should we handle this?

We could just allow anything in the specifier fields and let the fact that LegacyVersion and Version are now directory comparable to each other handle things. The problem with this is that something like >=1.1.5.jaraco.20140924 would essentially mean "any PEP 440 compatible version, and then anything >=1.1.5.jaraco.20140924 using the old style scheme.

Another solution is to add a LegacySpecifier which implements the old style of behavior. Projects like setuptools then would do a similar thing as is done now with versions where they first attempt to use the new behavior, and if it fails to parse it falls back to the old behavior. The problem with this one is, it's going to end up adding mixed specifier syntax where you might have some dependencies using the PEP 440 syntax and some dependencies using the old style. It also has issues with combining multiple specifiers, what do we do if two projects have a dependency on "foo>=1.0", which will be a Specifier instance and a dependency on foo>=1.0.wat which would be a LegacySpecifier instance.

[ncoghlan]

Perhaps the latter approach with a "--strict" flag to turn off the fallback would work?

That kind of compromise isn't uncommon as part of a transition like this.

[dstufft]

That could work, what would happen if you combine a LegacySpecifier and a Specifier? Would it "down cast" the Specifier into a LegacySpecifier? Should we expect that setuptools/pip/whatever else will deprecate these things and eventually remove support for LegacySpecifier or would we expect it to be something that lasts forever?

[dstufft]

For myself, Idon't think it's something that we're going to be able to realistically deprecate anytime soon. We might raise a warning on it but otherwise I don't know that we're going to be able to do anything about it because of the sheer mass of software out there that likely depends on at least one thing like this.

To that effect I wonder if a --strict flag makes sense or not. The problem I see with it, is that it's a very coarse knob and it's mostly going to help the people who are already on Specifier only behavior.

Perhaps the answer is, enable LegacySpecifier support, do the fallback shuffle like we do for versions, and actively raise a warning inside of packaging itself (vs packaging remaining neutral) for the use of them. If we're raising a warning if someone really wants the --strict behavior (which I think is most useful in tests) they can turn it into an exception with Python's normal warning control stuff.

The only thing I'm not sure about is what should happen if you do LegacySpecifier() & Specifier(), down cast? Error? Make it smarter so it'll turn into a MixedSpecifier() or something that will use Specifier() where possible and otherwise fallback to LegacySpecifier()?

[ncoghlan]

If the warning is "PendingDeprecationWarning", that could be an excellent
option. It's silent by default, so end users won't see it, and it
accurately reflects reality (we'd like to deprecate the legacy fallback,
but aren't yet sure when it may become feasible to do so)

[jaraco]

That all sounds straightforward to me.