[Distutils] PEP 440 and direct references

[Nick Coghlan]

On 26 Jun 2013 05:50, "Vinay Sajip" <vinay_sajip at yahoo.co.uk> wrote:
>
> I would find it helpful to understand the motivation for direct
references as
> defined in PEP 440, and some clarifications of how they can be used. For
> example:
>
> * Can they be used together with other clauses? As PEP 440 appears now, it
>   seems to indicate that they can, but what does it mean in practice to
have a
>   clause which is so specific with other clauses which are less specific?

While the intended use case is to pin a specific version, you could also
use a more general "latest" link and use other clauses to trigger an error
when the version changes beyond what you expect.

It's mostly because I don't think it's worth the hassle of banning such
combinations, though.

> * Can we have information in the "Direct reference" section summarising
where
>   such references can and can't appear?

No, because that will be up to tool developers.

> * What direct references provide which cannot be provided by the other
version
>   clauses together with (separately) URIs or paths for where archives can
be
>   found? The fact that the format of this clause is so different from all
the
>   others suggests that it doesn't really belong with them.

I'm guided by the fact that pip and similar tools all allow direct
references in requirement files. This is aimed directly at providing a
standard, command line friendly notation for such references, rather than
requiring the information be conveyed out of band.

Most of PEP 426/440 are about the shiny, happy packaging utopia we're
trying to create. This feature is aimed squarely at the messy world of the
system integrator.

>
> There are also questions on other areas:
>
> * It would appear that explicit prefix matching only makes sense for ==
and !=
>   clauses (as it is implicit for e.g.<, > clauses). If so, can this be
stated
>   explicitly?

It is already - none of the other clauses allow the trailing wildcard as
legal syntax.

> * Since pre-/post-/dev- suffixes are ignored for the purposes of prefix
>   matching, and given that implicit prefix matching is used with ~= , <
and >,
>   does this mean that explicit prefix matching is only useful for >=, <=?
>   (given that == with prefix matching appears equivalent to ~=)

Prefix matching is intended for cases where the prefix is shorter than
constraints in other clauses. For example, "~= 1.3" means ">= 1.3, == 1.*",
which is not the same thing as "== 1.3.*".

The only time a compatible version clause and prefix matching are
equivalent is for the "~= X.0" and "== X.*" case.

>
> It would also be useful to document what kinds of matches would not be
possible
> without ~= and explicit prefix matching (trailing .*), assuming we had
implicit
> prefix matching for ==/!= clauses.

That was the approach I took in earlier versions of the spec, but people
objected loudly to "==" not giving them exactly the stated version. So I
switched the prefix matching to being explicit instead.

The compatible release clause notation is mostly about encouraging the use
of appropriate API versioning semantics (although again, with plenty of
alternatives to handle the fact the real world isn't that neat and tidy).

Cheers,
Nick.

>
> Regards,
>
> Vinay Sajip
>
> _______________________________________________
> Distutils-SIG maillist  -  Distutils-SIG at python.org
> http://mail.python.org/mailman/listinfo/distutils-sig
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20130626/bbb11ed6/attachment.html>