[Distutils] PEP 440 and prefix matching

Daniel Holth dholth at gmail.com
Thu Jun 27 14:45:34 CEST 2013


FYI semver 2.0.0 final was released :-) semver.org

On Thu, Jun 27, 2013 at 7:24 AM, Nick Coghlan <ncoghlan at gmail.com> wrote:
> On 27 June 2013 19:16, Vinay Sajip <vinay_sajip at 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   |   ncoghlan at gmail.com   |   Brisbane, Australia
> _______________________________________________
> Distutils-SIG maillist  -  Distutils-SIG at python.org
> http://mail.python.org/mailman/listinfo/distutils-sig


More information about the Distutils-SIG mailing list