[Distutils] Environment marker expression types

[PJ Eby]

On Fri, Apr 26, 2013 at 2:52 AM, Nick Coghlan <ncoghlan at gmail.com> wrote:
> Yes, I think I prefer this layout for runtime consumption. Getting the
> full value for a field would then just be something like:
>
>     # Core dependencies
>     deps = meta["requires"]
>     # Check dependencies for any specified optional components
>     for extra_name in extras_of_interest:
>         extra = meta["extras"].get(extra_name)
>         if not extra:
>             continue
>         deps.extend(meta["extras"].get("requires", ()))
>     # Check conditional dependencies
>     maybe_deps = meta["conditional"].get("requires")
>     if maybe_deps:
>         for dep in maybe_deps:
>             if some_marker_evaluation_api(dep["condition"]):
>                 deps.extend(dep["entry"])
>
> Good enough for a first draft, anyway :)

I think it's missing the part where it needs to get the conditionals
for the extras and extend those as well, but yeah.


> distlib would probably evolve some metadata abstraction that hides all
> that fiddling behind a property.

Indeed.  In pkg_resources' case, there already was such a property,
which I've modified to evaluate the conditionals during the metadata
load, where I expect the I/O overhead to outweigh the 90 or so
microseconds of calculation time to process a platform+python-version
conditional.

Actually, while I'm on that subject, I wonder what the parsing
overhead is going to be for the JSON metadata?  I guess as long as
it's done in C, it'll probably be ok.  I expect the main runtime
performance issue for metadata will just be avoiding reading the
metadata in the first place, by using filename-embedded info so a
directory read can load the critical info for all available packages,
not just the one of current interest.  Beyond that, keeping the
description in a separate file will keep any loads that do happen fast
(how often is the long description currently needed by anything other
than PyPI?), and entry keeping entry points in separate files should
minimize the number of loads when searching for entry points.  (Since
in general the entry points you're looking for are needles in a
haystack, it pays to not have to inspect every stalk of hay, but
instead proceed directly to the bits that are metal.  ;-) )