As someone who has gone through these phases already, we are endlessly optimizing around a non-problem: how about you instead focus on local development instead?
Whatever the problem is with it (picking up system Python? drop /usr/bin from path... picking up system libraries? take full control of PYTHONPATH and sys.path) can be more trivially resolved than monkeypatching your running Python environment and would allow you to get back to that extremely fast feedback loop we used to have in SW dev 20+ years ago.
Yes, your software needs to not be tightly coupled to your infra: but that's just good, old clean architecture, right?
I sometimes wonder if I am a minority, but I think the modern "let's stick it in a container" bunch is just more vocal. And like all the other historical abstraction layer cakes (thin-clients, VMs, only-runs-deployed-to-the-cloud...), sooner or later, we still realise only local-first can get us that (almost) zero latency for development and debugging with no additional effort if we do all the right things anyway.
jtmcivor•3w ago
Code is deployed in containers. Improved capabilities to debug those systems will be really helpful to me (and I'm sure many others). Recreating real-world state locally takes effort and is error prone
necovek•3w ago
As I said, you can either have better, cleaner architecture where the fact it's deployed to containers does not matter; or, you could decide not to deploy to containers if you are going to be breaking container boundaries in production systems anyway!
It's a pretty big cognitive dissonance to me: we move away from direct access to increase our security posture, and then put more effort to break the barriers we just put in. Next, we'll put more effort in to harden these backdoors, break them again to be more productive...
In most orgs that follow relevant secure development lifecycle standards and legislation, engineers usually won't be able to do that for legal reasons anyway (due to GDPR or CRA in EU; comparable laws in California or New York), so really, big orgs will require you to not debug live production system but log relevant information, and act upon it later.
Anyway, we are all bound to re-learn these lessons, so good luck to anyone entering the scene today :)
necovek•3w ago
Whatever the problem is with it (picking up system Python? drop /usr/bin from path... picking up system libraries? take full control of PYTHONPATH and sys.path) can be more trivially resolved than monkeypatching your running Python environment and would allow you to get back to that extremely fast feedback loop we used to have in SW dev 20+ years ago.
Yes, your software needs to not be tightly coupled to your infra: but that's just good, old clean architecture, right?
I sometimes wonder if I am a minority, but I think the modern "let's stick it in a container" bunch is just more vocal. And like all the other historical abstraction layer cakes (thin-clients, VMs, only-runs-deployed-to-the-cloud...), sooner or later, we still realise only local-first can get us that (almost) zero latency for development and debugging with no additional effort if we do all the right things anyway.
jtmcivor•3w ago
necovek•3w ago
It's a pretty big cognitive dissonance to me: we move away from direct access to increase our security posture, and then put more effort to break the barriers we just put in. Next, we'll put more effort in to harden these backdoors, break them again to be more productive...
In most orgs that follow relevant secure development lifecycle standards and legislation, engineers usually won't be able to do that for legal reasons anyway (due to GDPR or CRA in EU; comparable laws in California or New York), so really, big orgs will require you to not debug live production system but log relevant information, and act upon it later.
Anyway, we are all bound to re-learn these lessons, so good luck to anyone entering the scene today :)