pypa/packaging

Add a function to provide a "human readable" form of a specifier

Opened this issue · 6 comments

pfmoore commented

See pypa/pip#8220 for background.

Could a function be added that would return a "human readable" form of a SpecifierSet?

ei8fdb commented

@uranusjr @pfmoore @nlhkabu

Through PEP 440 we come across Arbitrary equality and it mentions:

Use of this operator is heavily discouraged and tooling MAY display a warning when it is used.

Some questions:

  1. Does pip support ===?
  2. If so, does it display a warning?
  3. If so, can you point us to the warning text?

It will be helpful to understand how pip treats this operator so we can try and give a useful error message to the user if they have used this operator.

pfmoore commented

I imagine pip would do whatever packaging supports.

I'm not at a PC where I can do this right now, but can't you just check by doing something like pip install click===7.1.2? (I think that's a valid click version). If there's a warning, it should be possible to grep it in the sources (which I can do for you if needed).

  • 👍1
brainwane commented

This came to my attention via this Zulip conversation.

Pradyun asked for more details on why we are considering doing this -- what the benefit is. And Paul mentioned

(It's details like these that I don't have a good feel for what @ei8fdb expects in a "human readable" format - I'm too close to the problem and the PEP 440 version looks more readable to me than versions spelled out in words...).

@nlhkabu gave an example in pypa/pip#8220 (comment) :
changing

<3.0.0,>=2.4.2 into lower than 3.0.0 but greater or equal to 2.4.2

I know that very experienced packaging experts, and some programmers, think that the one on the left is more readable. I am a programmer and more expert in Python packaging than many people. But when I look at those examples, the more symbol-heavy example on the left makes me feel a bit of despair, like, "Oh no, now I have to work out what that means." The version on the right makes me feel calm and like a person is talking to me and will help me solve my problem.

@pradyunsg does that help you understand one benefit of this (possible) approach?

pradyunsg commented

Thanks @brainwane!

I do understand that the symbol heavy nature of the notation isn't super great for anyone who isn't familiar with them / doesn't deal with them regularly, and how a more "plain English" format would be nice to have. However, I think it represents a not-insignificant amount of both design and implementation time, to implement this.

I have some concerns about how such information presented to non-English users would look like, and whether packaging is the correct place to put the logic for this "plain English" representation. I don't think I can judge the feasibility of implementation of such a function, and whether packaging is the right place to put it, right now. I'll wait till someone posts a more concrete proposal here, containing details of what this looks like, and how the message would be constructed.

brettcannon commented

I don't think 'packaging' is the right place for this. This is very much a UI/UX thing and this project doesn't provide support at that level.

pfmoore commented

I should note that I'm also not sure packaging is the right home for this. I used packaging purely as a placeholder for "not pip", as I definitely don't think this should be internal to pip. The problem is that if this doesn't go in packaging, the most obvious alternative place is a new, dedicated library. And that has a whole extra bunch of costs to set up that push the cost/benefit case even further towards "not worth it" 🙁