Change in behavior for 'requires.txt' in 36.2.0
See original GitHub issueIt seems setuptools
v36.2.0 changed the behavior of {package}.egg-info/requires.txt
generation. I suspect this was introduced by #1081. We saw this in pbr
as it broke our unit tests. We have since fixed this, but ideally this behavior shouldn’t have changed in a minor release.
I don’t want to revert that change but I also would like this behavior to remain as consistent as possible (for as long as requires.txt
files are used, anyway). I can work on a test to ensure this is the case.
Issue Analytics
- State:
- Created 5 years ago
- Comments:9 (9 by maintainers)
Top Results From Across the Web
Allow placement to start without a config file · 324e4f44da
Though this change is orthogonal to the oslo.config change, requirements and lower-constraints are updated to ensure the desired behavior.
Read more >pip freeze creates some weird path instead of the package ...
I use pip freeze > requirements.txt to add the required package into the requirement.txt file. However, I realized that some of the packages, ......
Read more >Just Enough Items (JEI) - Mods - Minecraft - CurseForge
Transition various string based APIs over to text components (#2306) - Sara ... Only require IRecipeWrapper for vanilla crafting recipe extensions - mezz ......
Read more >User Guide - pip documentation v22.3.1
python -m pip freeze > requirements.txt python -m pip install -r requirements.txt ... in your requirements file, then replace that line with the...
Read more >What is the python requirements.txt? - I Don't Know, Read The ...
Especially if it is a larger project. So you want to keep track of what version of each package you are using to...
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
@pganssle: yes, it’s easier, I have no problem with us implementing/testing it that way. The issue is with other projects doing the same.
@benoit-pierre I guess the other side of this is that guaranteeing a specific order is probably in many ways easier than guaranteeing that the order is stable (since we can always re-order the outputs at the very end), and it’s much easier to test for guaranteed-order than it is to test for stable-order.
@jaraco If you’d like I’m happy to write a new test that checks that this works in some order-independent way, though I’m warming up to the idea of “we should sort anything where we weren’t guaranteeing order”, for purposes of build reproducibility, in which case this test seems fine.