On Thu, Sep 10, 2015 at 11:34 AM, Daniel Holth <dho...@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. _______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
