Merge of python and ruby PostgreSQL drivers

[larskanis]

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?

      Because it doesn't work! 😌

But it could! Just use pycall!

      We make the switch! In pg-1.4.2022 ! 😳

      Be prepared and install python today! 😉

[ged]

This will be so much easier. Thanks for doing this!

[ariccio]

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 :)

[ryanb]

@ariccio this is for a message that only shows up on April 1. 😉

[ariccio]

LMAO chef's kiss

[doconnor-clintel]

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. Putting something like this into the changelog itself; rather than code which is executed by tools like bundler would likely have had less of an impact.

[ariccio]

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 🤣

[pavels]

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. Putting something like this into the changelog itself; rather than code which is executed by tools like bundler would likely have had less of an impact.

Disclaimer: i am not affiliated with the author, just saw the message and followed the link:

IMHO

a) it is funny b) see https://en.wikipedia.org/wiki/Chaos_engineering - in other words, things like this actually help us as and the industry as a whole to be more resilient towards disruption. Your tools should not break under this conditions and so does others. Let's make computing less fragile, one system at a time :) c) "basically a supply chain attack" - well, it is actually not - but you can take this as a security drill - just keep in mind the real attack will not have giant message with a link in it.

[doconnor-clintel]

Sounds to me like this gem just did some unintentional QA for you

and

a) it is funny

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: 180,716,082

For this version: 18,690 (in 24 hours!)

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?

• Healthcare
• Law enforcement
• Defence
• Finance
• Security
• Property

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.

[larskanis]

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:

Matsumoto has said that Ruby is designed for programmer productivity and fun, following the principles of good user interface design.[81] At a Google Tech Talk in 2008 Matsumoto further stated, "I hope to see Ruby help every programmer in the world to be productive, and to enjoy programming, and to be happy. That is the primary purpose of Ruby language."

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! :smiley:

[larskanis]

Oh sorry @pavels I deleted you comment by accident!

[simi]

Damn, you got me for a minute @larskanis. :partying_face:

[pavels]

@larskanis whatever :smile: 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.

:heart:

[yshmarov]

😆

[casi]

That's why I hate the first of April with all my heart. Okay, one of the reasons. ;)

[ghost]

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.

[thepeoplesbourgeois]

I say this not from simply a cost perspective, but from a quality, risk and safety perspective.

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.

[moapwr]

chaos engineering and similar are intentional, opt in choices

pulling code from the interwebs is considered an opt-in to chaos engineering

[jirihradil]

Ha. Ha.

[rchasman]

Great stuff! Thank you for maintaining this Gem and having fun with it!