On 26 Jun 2013 05:50, "Vinay Sajip" <[email protected]> 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 - [email protected] > http://mail.python.org/mailman/listinfo/distutils-sig
_______________________________________________ Distutils-SIG maillist - [email protected] http://mail.python.org/mailman/listinfo/distutils-sig
