j: Next unread message
k: Previous unread message
j a: Jump to all threads
j l: Jump to MailingList overview
On 8 November 2015 at 17:10, Nathaniel Smith email@example.com wrote:
On Sat, Nov 7, 2015 at 12:32 PM, Robert Collins firstname.lastname@example.org wrote:
On unknown names, current pkg_resources raises SyntaxError. So I think we need to update the spec from that perspective to be clear. All PEP 426 defined variables are handled without error by current pkg_resources/markerlib implementation. Perhaps the new variables should raise rather than evaluating to '' / 0 ? Some discussion / thought would be good. Certainly when used and evaluated by an existing pkg_resources they will error - so perhaps we should not add any new variables at this point?
I just thought of one possible strategy for allowing future extensions without opening the door wide to every typo: add a variable which contains the version number of the environment marker evaluation system, define the and/or operators as being short-circuiting, and keep the rule that trying to access an unknown variable name raises an error. Then you could use write things like:
# 'foo is only really needed if some_new_attr > "2", but doesn't hurt otherwise.
# So when using an old installation tool that doesn't know about some_new_attr,
# install it unconditionally.
Requires-Dist: foo; marker_handling >= "2" and some_new_attr > 2 Requires-Dist: foo; marker_handling < "2"
It's a decent strategy, but unfortunately a breaking change to introduce it. I think right now we should just not introduce new symbols, since we have such a long runway before they can be used, and instead look for an opportunity where another break is required, and we can bundle them together.
-- Robert Collins email@example.com Distinguished Technologist HP Converged Cloud