On 27 June 2013 19:16, Vinay Sajip <vinay_sa...@yahoo.co.uk> wrote: > All the examples of explicit prefix matching in PEP 440 show only release > clause components, but it's not explicitly stated whether that's > specifically intended. For example, are prefix matching clauses such as > > == 1.2.dev0.* > != 1.2.post1.* > > allowed?
Sure. I'm not sure why anyone would actually want to do it, but it's allowed (disallowing it would actually make the spec more complicated rather than simpler). The only thing which explicitly ignores the suffix is the compatible release clause: "If a pre-release, post-release or developmental release is named in a compatible release clause as V.N.suffix, then the suffix is ignored when determining the required prefix match" The rationale for that restriction is that we're mostly using the same compatible release semantics as semantic versioning, except that we assume a reasonable level of backwards compatibility will exist even for 0.x releases, leaving it to people to use prefix matching if a dependency exposes a somewhat unstable API. Semver doesn't define compatibility semantics outside the release number, so we don't either. It occurs to me, though, given that we now have an exact prefix matching notation for more unusual forward compatibility constraints, we *could* just make all compatible release clauses explicitly semantic versioning based. Then you could say things like (2.2.2) or (~= 2.2.2) to mean (>= 2.2.2, == 2.*). Under the current PEP, those clauses would translate to (>= 2.2.2, == 2.2.*), which differs for no good reason I can see from the handling of a clause like (~= 2.2.post1), which would translate as (>= 2.2.post1, == 2.*). I think the semantic versioning based system is actually easier to explain than the current scheme (mostly because it's more consistent), so unless someone comes up with a compelling counterargument in the next few days, I'll switch the specification to always use "== V.*" as the prefix matching component of a compatible release clause, no *matter* how many components there are in the version specifier itself. Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia _______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
