Logical OR for version specifiers
See original GitHub issueAccording to PEP 440,
The comma (“,”) is equivalent to a logical
and
operator: a candidate version must match all given version clauses in order to match the specifier as a whole.
There does not seem to be an equivalent for logical or
.
For example, if slash (“/”) was used for this,
>=2.7,!=3.0.*,!=3.1.*,!=3.2.*
could be simplified using compatible release operators:
~=2.7/~=3.3
Issue Analytics
- State:
- Created 6 years ago
- Comments:14 (3 by maintainers)
Top Results From Across the Web
PEP 440 – Version Identification and Dependency Specification
A version specifier consists of a series of version clauses, separated by commas. ... The comma (“,”) is equivalent to a logical and...
Read more >Versions of dependencies - Yarn
When developers talk about two semver versions being “compatible” with one another they are referring to the backwards-compatible changes ( minor and patch...
Read more >About semantic versioning - npm Docs
Incrementing semantic versions in published packages ; First release, New product, Start with 1.0.0, 1.0.0 ; Backward compatible bug fixes, Patch release ...
Read more >Versions and constraints - Composer
Composer uses version constraints to figure out which refs in a VCS it ... Ranges separated by a space ( ) or comma...
Read more >Dependency version syntax for Python Poetry - Stack Overflow
If poetry update finds a newer version that is allowed by your version specifiers, it will download and install it. It will also...
Read more >Top Related Medium Post
No results found
Top Related StackOverflow Question
No results found
Troubleshoot Live Code
Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start FreeTop Related Reddit Thread
No results found
Top Related Hackernoon Post
No results found
Top Related Tweet
No results found
Top Related Dev.to Post
No results found
Top Related Hashnode Post
No results found
Top GitHub Comments
Actually this idea is not possible because the requirement specifier is not a logically complete system (parentheses are not supported). So a PEP will be required; I would recommend that you join distutils-sig and propose this idea there.
I don’t think the json metadata is moving forward.