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
New Option for Dynamic Versioning, e.g. wheel==0.23.*, wheel==0.* or wheel #237
Conversation
* added new option for dynamic versioning * added quotes for dynamic options Co-authored-by: Siyang <teo_siyang@imda.gov.sg>
4 similar comments
Hi, thank you for the PR! This seems like a good opportunity to also add support to the compatible release version specifier as a scheme, what do you think? |
@alan-barzilay Saw u commented at the other post, glad there's a new maintainer to help out in this important library. :) Can I understand the reason to add the compatible release format? Since, the current format using asterisks in this PR kinda achieves the same purpose. If compatible release is a standard by PEP 440, and My team and I will be happy to settle any issues related to this PR efficiently, as this feature is something our team will like to incorporate. :) |
My understanding of the compatible release format is that it is useful if you want to ensure that you will have a compatible version of a package. Lets say you have a package in version 3.1.2 in your current project. By using ~=3.1.2 in your requirements, you will guarantee that you will get version 3.1.2 or later, but not version 3.2.0 or later. If you need a feature that was introduced in version 3.1.2 this will guarantee that you will have it, but it also guarantees that you will not get version 3.2.0 or later since a breaking change may have been introduced. I agree that using asterisks kinda achieves the same purpose but I believe using the ~= notation would provide a more robust requirements.txt. Maybe we could adapt the micro and minor schemes to use ~=? The micro scheme would simply use the compatible release notation and the minor scheme would also use ~= but only after stripping everything after the second ".". This approach would also have a smaller code surface to worry about. If I may, I have a suggestion that would also contemplate PR #107.
What do you think? |
@alan-barzilay thanks for the detailed explanation. It makes sense, and also a good idea to consider PR #107. As they sort of belong to the same family, should we lump them together as a single option like below? Do edit the wordings if I used any of them inappropriately.
|
I have a question for you @mapattacker, what is the use case that you envisioned for the minor scheme?
Agreed! I edited a few things to make it more succinct and intuitive, let me know what you think :) (I skipped the minor scheme because I couldn't think of an intuitive/descriptive name for it, maybe something like weak or relaxed compatibility? )
|
@alan-barzilay That's a good question haha, our main goal for this PR is actually for the micro/compat scheme. I just thought there might be somebody who might value a minor scheme update for some reason. I guess till someone require it, then only it makes sense to include in. The code changes will be a lot simplified without that option too.
I think for this line, I feel we should remove If the above are ok, me and @Jcch94 should be able to update the PR pretty soon. |
Ok! Lets drop the minor scheme then and remove the "explanation" for the compat mode.
|
* fixed MySQL + krbV mappings to be reversed * Working on issue bndr#88 * More --clean tests. * Fixed bndr#88 * mapping aws-sam-translator https://pypi.org/project/aws-sam-translator/ https://github.com/awslabs/serverless-application-model * Fixed#133 Sorted `imports` based on `lowercase` package's `name`, similar to `pip freeze`. * Tweak formatting * Add pyAFQ Mapping * Add discord mapping Map discord to discord.py * Add PyFunctional mapping Maps `functional` to `pyfunctional`. Fixes bndr#232. * Upgrade pip before running tests on travis This should ensure that all tests use the same version of pip and this should hopefully fix the pypy build that is using pip 19 * Upgrading pypy to pypy3 Maybe forcing pypy to use python 3 will solve the issue (although it works fine with python 2.7 at the moment) * Remove unecessary pip upgrade step * Mapping for github3 * changes based on discussions w maintainer * remove obsolete '==' Co-authored-by: Hari Sekhon <harisekhon@gmail.com> Co-authored-by: AlexPHorta <alexandre.horta@gmail.com> Co-authored-by: Pat Myron <PatMyron@users.noreply.github.com> Co-authored-by: Abhishek Kumar Singh <toanant@users.noreply.github.com> Co-authored-by: Ben Bodenmiller <bbodenmiller@gmail.com> Co-authored-by: John Kruper <36000@users.noreply.github.com> Co-authored-by: Paweł Kalemba <5924586+pkalemba@users.noreply.github.com> Co-authored-by: SwiftWinds <12981958+SwiftWinds@users.noreply.github.com> Co-authored-by: Alan Barzilay <alan-barzilay@users.noreply.github.com> Co-authored-by: alan-barzilay <alan.barzilay@gmail.com> Co-authored-by: ryan-rozario <ryan.rozario1999@gmail.com> Co-authored-by: Siyang <teo_siyang@imda.gov.sg>
Feature implemented in PR#239 |
Added new option "dynamic", for dynamic versioning.
Example:
wheel==0.23.0
There will be 3 possible args for this option, micro, minor or all. The result in requirements.txt will be as below.
This will enable more targeted installations, esp if one is only looking at bug fixes, security patches or minor/micro version updates, or simply just install most recent updates.
--no-pin
option is merged within this new option as the "all" arg.@Jcch94