Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
Fixes #999: support python_requires and py_modules in configuration files #1007
Concerning the last point:
referenced this pull request
Apr 7, 2017
For future commits, I would recommend instead of committing all the changes in one commit and then explaining the changes in the PR, I'd prefer if you made several commits, each with a commit message explaining what you've explained above. The advantage to that approach is that in a year from now, if someone is tracing through the code history to understand why (for example) the error message was changed, they would readily find a description of the reason, rather than see what looks like a change incidental to the intention of the commit (and then being left to wonder if the change was intentional or incidental or accidental) and if they're lucky, tracing the commit message to the ticket to the PR for more detail. Separate commits also enables selective acceptance and rollback of independent changes.
Hi @idlesign, well I only followed
And I'm with @webknjaz on this: In comparison to the other
I'll try to break it down. Let's think about it the following way:
If so, we deal with the following two entities:
The same as with:
Requests 2.18 is the same as 3.15? Probably not, despite of the name we have two different applications. And we tokenize
The idea is: if we have different entities they should be in different slots.
And if I use
@idlesign AFAIK separate entries like
requests == 2.18 requests >= 3.15
Would cause pip do
requests == 2.18, >= 3.15
then it would fail instantly when trying to install requirement with two incompatible restrictions.