[Distutils] platform_python_implementation not implemented.

[PJ Eby]

On Thu, Sep 10, 2015 at 11:34 AM, Daniel Holth <dholth at gmail.com> wrote:
> That is too bad. markerlib was added to pkg_resources as _markerlib in 2012.
> It is used for .dist-info metadata as present in wheel. Then, only to
> implement markers to setup.py or .egg-info style metadata, pkg_resources
> gains its inline markers implementation in 2013, including its own
> definitions of the key/values used in environment marker comparisons. Dots
> switched to underscores in revision aa74cf234684 in the inline
> implementation and in revision 1fc8a2d94f9f for setuptools' vendored
> _markerlib.

To clarify: the Distribute fork of setuptools added _markerlib, but
Distribute didn't support older version of Python as the official
setuptools 0.6 did, which is why I added the inline version there.
There was also active discussion at the time about changing the
markers spec, as Nick was working on PEP 426.  Previously, there were
two other PEPs, 345 and 390, with their own not-quite compatible
specs, and more recently there is now a PEP 496.

So, there has never really been a stable standard for environment
markers; all of the previous specs have had various ambiguities,
underspecification, or excessive lenience.  My hope at the time of the
PEP 426 discussion was that we could define a *strict* grammar in
place of a loose pseudo-grammar so that the spec would be robust to
multiple implementations rather than forcing everyone to copy the
quirks of one particular implementation (e.g. markerlib).

Unfortunately, even PEP 496 is still a little underspecified: it
doesn't even say what kinds of string literals are allowed, address
encodings or character sets, etc.  Is r"foo" a legal string
expression?   Can you use double-quotes?  Backslash escaping?
Adjacent string literal concatentation?  But it's better than the
previous versions, since the mini-language is no longer an
ambiguously-defined subset of Python and thus can no longer be parsed
using Python's built-in grammar, and probably not its lexer either.


> I would prefer to see _markerlib._VARS used everywhere, the inline
> pkg_resources implementation deleted, markerlib improved if necessary, and
> no backwards compatibility with unspecified environment marker variables. My
> hunch is that no one needs the backwards compatibility.

It may have changed since when I added markers to the official
setuptools, but I intentionally did not document the marker feature;
it was experimental and added mainly to support setuptools' internal
use case of including SSL backports on older Python versions to
support easy_install checking SSL certs.  So, anybody using it was
(and perhaps is; I haven't looked lately) using an undocumented
experimental feature rather than an officially supported one.

In any case, if compatibility is broken, it should probably be done by
switching to the much-stricter PEP 496, rather than one of its
even-more-ambiguous predecessors.