-
Notifications
You must be signed in to change notification settings - Fork 171
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鈥檒l occasionally send you account related emails.
Already on GitHub? Sign in to your account
Merge of python and ruby PostgreSQL drivers #449
Comments
This will be so much easier. Thanks for doing this! |
As someone who knows absolutely nothing about what you're actually doing behind the scenes to make this work, will this cause problems for deployment? I'm thinking about my heroku buildpacks. I'm generally in favor of the idea of dropping down to only one implementation! I think the CPython interpreter is some of the ugliest C I've ever seen, especially compared to the beautiful-ish C behind the Ruby interpreter, but enough people like python that I will trust that you're making the right decision here :) |
@ariccio this is for a message that only shows up on April 1. 馃槈 |
LMAO |
Yes, this has caused problems for deployment pipelines in the wild. While our [very ancient] tools probably shouldn't be so fragile as to break with content like this, the real world impact has been engineering time figuring this out for what is basically a supply chain attack. I'd discourage you from this sort of thing if possible; considering the scope and adoption of the gem; plus the combination of automated build and dependency tools. |
Wait, something in your tool chain actually broke? I was worrying that I would actually need to make sure my build pipeline had the python environment setup, not having problems right now... Kinda why I thought it was excellent. What was your tool doing? Comparing the raw console output? Sounds to me like this gem just did some unintentional QA for you 馃ぃ |
Disclaimer: i am not affiliated with the author, just saw the message and followed the link: IMHO a) it is funny |
and
Yeah. So here's the problem with that - chaos engineering and similar are intentional, opt in choices. Our organisation chose to use what they regarded as a reasonably well trusted public dependency of high enough quality for database connectivity; but did not opt in to this methodology. While this was caught very early on in the piece (why I'm here pointing out this was a particularly silly thing to do; rather than dealing with spot fires); it incurs a engineering time and effort to banish the deliberately tainted dependency that could be better spent elsewhere. I say this not from simply a cost perspective, but from a quality, risk and safety perspective. Total downloads of this gem: For this version: If you assume 1 in 500 of those encounter a bug, and then 5% of those slip through a code review due to human error, then perhaps 5% more of those slip through CI/CD gates; you end up with: (18690 * 30 days) / 500 * 0.05 * 0.05 = ~2.8 deployments/installs/etc a month broken by this; or up to ~33 a year. What is the likelyhood that any of these industries using Ruby + Postgres?
What's the likelyhood of harm occurring to people if systems in those areas experience problems? Small, but not zero. Where if this had simply been done in a changelog or as some another announcement, that risk would be a lot closer to zero. |
Thank you all who participated in this small April Fool, so far! I hope you recognized it as a joke and enjoyed it! Please don't forget the philosophy of ruby:
You can feel certain, that we'll continue the good work to develop and maintain this important database driver. And for sure, pg-1.4.x will bring new improvements, that I don't know today, but it will certainly not require you to install python to run ruby! @doconnor-clintel Don't panic! Look into the commit and see that the message comes out today only. Just settle back and smile! 馃槂 |
Oh sorry @pavels I deleted you comment by accident! |
Damn, you got me for a minute @larskanis. 馃コ |
@larskanis whatever 馃槃 so be it I just really like these small things that happens here and there (like the (in)famous message after installing https://github.com/jnunemaker/httparty ) and wanted to voice support. And i still strongly believe that we should strive to build more resilient systems that don't tend to break with changes like this. 鉂わ笍 |
馃槅 |
That's why I hate the first of April with all my heart. Okay, one of the reasons. ;) |
Why would you make a production deployment system this fragile? Who in their right mind would then use such a monstrosity in healthcare? Fix your own system don't expect the world to do it for you. It is, indeed, funny. Finally an April fool doing it right. |
I too believe that it is better from a quality, risk, and safety perspective for brittle, unexamined systems to remain that way, up until (& after?) a truly malicious attack or large-scale natural disaster completely levels said systems, resultantly toppling civilization as we know it. |
chaos engineering and similar are intentional, opt in choices pulling code from the interwebs is considered an opt-in to chaos engineering |
Ha. Ha. |
Great stuff! Thank you for maintaining this Gem and having fun with it! |
Never thought about the need to write drivers again and again for every programming language? Why not use one and the same code base for multiple language?
But it could! Just use pycall!
The text was updated successfully, but these errors were encountered: