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
Remove version pinning #432
Comments
@dvzrv Can you create a PR example and go into greater detail. Does Arch packaging rely on Pipfile, or setup.py -> requirements/base.txt? |
It'd be helpful to clarify if Pipfile plays a role in the packaging (I only really use Pipfile for development). And second, what would a requirements/*.txt / Pipfile look like that didn't conflict downstream. I'd like to be helpful as possible to packagers, but would like an example. Some considerations: click < 7 isn't supported yet, and we need a minimum version of pyyaml for python 3.7 support. |
@tony sorry for the misunderstanding: I meant this more as a general recommendation! However, I thought the Pipfile displayed the current use of all requirements (and I was kinda right). Arch, being rolling release, updates to latest stable pretty fast (with whatever breakage that might bring). That is an obvious downside to slow moving projects, but on the other hand there really is no upside to version pinning all your requirements (with |
On the |
Correct We will target 1.5.0 to be click 7.0 compatible I'll release 1.4.2 which will includes tests in the sdist. |
@tony please consider making this a higher priority, as tmuxp is now not working anymore:
To get back on topic: More hard version pinned requirements will break tmuxp, even if that dependency works in a higher version. |
@dvzrv There's also a reason why we enforce constraints, for instance: Click 7 will break tmuxp. That's why that's pinned. Click 7 PR: #434 Re:
I believe 1.4.1 and 1.4.2 is click < 7.
I've had the opposite issue. I've had the issue before where not pinning ended up breaking tmuxp for a lot of users: #399 (comment) So see where I'm coming from? If I don't have some constraint, it's possible that a dependency could have an API break that would otherwise not be a holdup. When I create a pin (sometimes I may be wrong and we should remove the pin) but the idea is we're preventing a potential break. So I think, maybe, there's three issues to distinguish from: pin that are bad that cause breakages, pins that help protect from breaking (e.g. enforcing click <7 until we support it) and catching up with downstream dependency versions used in package managers. Is arch using click 7 and us not being updated blocking? (Shouldn't we be expected to have some time to update? We didn't know click 7 was going to be released, let alone it'd break API's and not even have a migration guide to explain why) |
Hi @tony, I think what we need is a middle ground. The current pipfile freezes every dependency. What I think we need is to freeze only ones that break tmuxp for one reason or another, until cycles to address the problems comes or based on release cycle. Here is an example of Pipfile, with this in mind: This is from requests package, which is from the same author as pipenv. I think we can understand / accept this as best practice. If everyone is ok with this approach, I would be happy to put in pull request by tomorrow. Please let me know. |
Feel free to assign this issue to me. Happy to help. |
@dvzrv - Believe this has been addressed now, in a recent merge. Can you please try again and let us know so we can close this issue? Thanks! |
Closing this issue due to inactivity. We believe the issue / request has been addressed. If there are still any problems around this, please advise us by create a new issue, possibly referencing this one. Thanks! |
@rfoliva sorry for not getting back earlier. I have many packages and life ;-) I guess this issue is not really solved, as there are still hard version requirements, that break tmuxp (see #445 for current issues with colorama, which I even mentioned earlier in this issue). I think I can only remove all hard version pinning for this package to function properly in the future on the OS level. Even if that potentially breaks functionality, when a dependency is updated, it at least attempts to use it in the first place. |
Thanks @dvzrv. What version are you tracking for this Arch package? Any specific tag? I have pushed the unpinning on to master using Pipfile / Pipfile.lock, so I believe it has not been applied to version you are tracking. How are you building your package? Using OS repos (stable / dev). I have been meaning to reach out to package maintainers to find out how they build their packages and see how we can help, make your like easier. If I have this information, we can keep it in mind and try to help. Thanks, |
@dvzrv from what I could see from this link you provided on another issue, you are using the requirements files to build your package and this is where you did the version unpinning. I can do the same on our side, but we need to make sure 1.5.0a takes these changes as well. Please confirm I am on the right track and I will make this happen. Thanks, |
@rfoliva yes, as mentioned here, we use setuptools. I do understand, that hard version pinning makes sense in a development process, but it is also a bit painful for Arch maintainers ;-) The way it is right now (with sed'ing the pinned versions) it works for me, but it will definitely break tmuxp, if there are incompatibilities. In general, I'd rather have that though, than an enforced upper limit, as if things break, people can actually give you useful stacktraces (my stuff breaks with tmuxp and dependency in version x.y.z). |
I think this should be addressed officially with release of 1.5.0. No need for alpha anymore. Can you please confirm @dvzrv so we can close it? Thanks! |
Thanks this is solved by the recent changes! And sorry for the long overdue reply! |
@dvzrv No problem! Good this is working now! |
The Pipfile lists many version pinned requirements.
IMHO requirements should ideally never be version pinned (only if really really required).
Please remove the version pinning, where not needed!
It's hard to do proper packaging with this (especially for distributions, that follow upstream closely, such as Arch Linux).
The text was updated successfully, but these errors were encountered: