Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Improve ergonomics of Requirement.marker evaluation #271

Open
uranusjr opened this issue Feb 10, 2020 · 0 comments
Open

Improve ergonomics of Requirement.marker evaluation #271

uranusjr opened this issue Feb 10, 2020 · 0 comments

Comments

@uranusjr
Copy link
Member

Currently Requirement.marker is of type Optional[Marker], and the following code is needed to check whether a requirement needs to be resolved:

def needs_resolution(r: Requirement) -> bool:
    if not r.marker:
        return True
    return r.marker.evaluate()

which becomes cumbersome quickly. I can think of three ways to improve the interface:

  1. Allow Marker('') that always evaluate to True (similar to SpecifierSet('')), and use that to indicate no markers instead of None. This could be a problem if people are checking for marker is None, but I think most of the use cases should also be compatible with evaluate().
  2. Similar to 2., but do this with another class EmptyMarker. This has most of the same problems as above, and may also be a problem for people doing isinstance(marker, Marker). Maybe this can be worked around with __subclasscheck__?
  3. Introduce a convinience method Requirement.evaluate_marker() that encapsulate the above logic. This is the least disruptive change, but could be a bit confusing.
@pradyunsg pradyunsg changed the title Improve egonomics of Requirement.marker evaluation Improve ergonomics of Requirement.marker evaluation Dec 8, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants