-
Notifications
You must be signed in to change notification settings - Fork 1.9k
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
Pin pyjnius version #1416
Pin pyjnius version #1416
Conversation
Thanks for the pull request!
It's more a matter of personal taste than a pro tip. |
If pinning gets done, which is actually a good idea, please make at least a tag of pyjnius. |
@rnixx PyJNIus is already prepared for simple deployment via Travis, you can test it with Also the issue is the same one that broke the patches (because me + style checkers and making it more readable) 😄 Fixed in #1417. |
This is now "conflicting" with #1417 |
Shouldn't #1417 just update the pin with exactly that merge? That is the point of having a pin, updating it along with all changes that make things incompatible, such that no arbitrarily incompatible versions of patch & pyjnius or whatever are combined. So in my humble opinion the pin should be set as early as possible, and then anything that changes things that don't work with this pin should simply update the pin in that same changeset Edit: ah, already got merged. well, at least that would be a good process for the future |
@rnixx I have been thinking about your comment, and I'm wondering, while pinning a tag seems helpful for major releases, wouldn't it be better to stick with pinning to commits for Otherwise it'll either be a huge amount of tags, or |
Summary of my opinions from discord:
|
@inclement I'll sure be jumping ship from using master even if such pyjnius breakage only happens rarely. The problem is not the breakage itself, but that it's not pinned / reproducible for one commit, that's just pure acid for any actual deployment use even for the more adventurous. So if you want people to test it, I think leaving this unpinned won't necessarily do you a favor. Also, for Python 3, the p4a stable is pretty useless right now given how much doesn't work with it. But of course that could change with upcoming releases. Edit: or maybe stable has already received updates, I admit I haven't been closely tracking it. But at least whatever is on pip wasn't in a good shape (for python 3 use, that is) last time I tried it, if that's actually the stable version |
Pinned in p4a stable to begin with #1426 |
I've just created #1427 to pin on the last freshly created tag. |
I really couldn't care less about credits especially for such a minor change, so if it's less work, just merge it in 👍 |
Pins pyjnius==1.1.3, fixes #1416
This pull request adds a version pin for pyjnius as requested here: #1415
Please note I am proposing this as a permanent measure because this is such a core component - not this specific version of course, but that it is always pinned.
Even if you just randomly bump the version up in any random commit without checking, this is a huge improvement: it will prevent p4a master builds from randomly failing out of the blue when not even changing the commit, and people will be able to go back to an earlier p4a master commit to avoid sudden pyjnius breakages instead of patching around in the recipes folder (which depending on the build pipeline might be quite a time waster to do, especially compared to just going back to a known working p4a master commit).
Summed up, please pin this, carelessly bump it whenever, and have less unhappy users. 😄
(And I'm not proposing pinning everything, I know you have way too many recipes and people would forget to bump it, I understand - but at least the core components like pyjnius, would that possibly sound feasible?)