Something like this:

    try:
        import requests
    except ImportError:
        from pip._vendor import requests

Go does this well, to the point where a lot of people in the community say "you don't need a library" for most use cases, only for e.g. database drivers. This is contrary to what a lot of developers believe, that they need e.g. a REST API library or enterprise application framework as soon as possible.

I develop as a pure amateur and there are areas I would never get into without libraries.

First are dates, it is a world of pain. Arrow is the answer (in Python)

Then HTML, another world of pain perfectly described in a Stack Overflow answer. Beautifulsoup.

HTTP is arguably easier but requests! :)

At some point there is a risk assessment to do and one should make decisions based on that. Kudos for having gone that way yourself!

I go out of my way to avoid Javascript. Because in all my years of writing software, it has 100% of the time been the root cause for vulnerabilities. These days I just use LiveView.

I'm actively moving away from Node.js and JavaScript in general. This has been triggered by recent spike in supply chain attacks.

Backend: I'm choosing to use Golang, since it has one of the most complete standard libraries. This means I don't have to install 3rd party libraries for common tasks. It is also quite performant, and has great support for DIY cross platform tooling, which I anticipate will become more and more important as LLMs evolve and require stricter guardrails and more complex orchestration.

Frontend: I have no real choice except JavaScript, of course. So I'm choosing ESBuild, which has 0 dependencies, for the build system instead of Vite. I don't mind the lack of HMR now, thanks to how quickly LLMs work. React happily also has 0 dependencies, so I don't need to switch away from there, and can roll my own state management using React Contexts.

Sort of sad, but we can't really say nobody saw this coming. I wish NPM paid more attention to supply chain issues and mitigated them early, for example with a better standard library, instead of just trusting 3rd party developers for basic needs.

If leftpad, electron, Anthropic, Zed, $shady_library$ gonna help developers beat that obstacle, they'll do it instantly, without thinking, without regret.

Because an app is not built to help you. It's built to make them monies. It's not about the user, never.

Note: I'm completely on the same page with you, with a strict personal policy of "don't import anything unless it's absolutely necessary and check the footprint first".

I think maybe the pendulum needs to swing back a little to being very selective about adding dependencies and expecting releases to be stable for the long term. Users shouldn't have to worry about needing to hack around code that was written just 3-4 years ago.

I agree that I wouldn't roll my own crypto, but virtually anything else? I'm pretty open.

When I was doing Perl more I actually highly liked the Mojolicious module for precisely this reason. It had very few external dependencies beyond Perl standard libs and because of this it was possible to use it without needing to be plugged into all of CPAN.

But with the libraries it provided on its own, it was extremely full featured, and it was otherwise very consistent with how you'd build a standard Web app in basically any modern language, so there was less of an issue with lockin if you did end up deciding you needed to migrate away.

I don't know many people who have shit on Java more than I have, but I have been using it for a lot of stuff in the last year primarily because it has a gigantic standard library, to a point where I often don't even need to pull in any external dependencies. I don't love Oracle, but I suspect that at least if there's a security vulnerability in the JVM or GraalVM, they will likely want to fix it else they risk losing those cushy support contracts that no one actually uses.

I've even gotten to a point where I will write my own HTTP server with NIO (likely to be open sourced once I properly "genericize" it). Admittedly, this is more for pissy "I prefer my own shit" reasons, but there is an advantage of not pulling in a billion dependencies that I am not realistically going to actually audit. I know this is a hot take, but I genuinely really like NIO. For reasons unclear to me, I picked it up and understood it and was able to be pretty productive with it almost immediately.

I think a large standard library is a good middle ground. There's built in crypto stuff for the JVM, for example.

Obviously, a lot of projects do eventually require pulling in dependencies because I only have a finite amount of time, but I do try and minimize this now.

I think the continuous churn of versions accelerates this disregard for supply chain. I complained a while back that I couldn't even keep a single version of Python around before end-of-life for many of the projects I work on these days. Not being able to get security updates without changing major versions of a language is a bit problematic, and maybe my use cases are far outside the norm.

But it seems that there's a common view that if there's not continually new things to learn in a programming language, that users will abandon it, or something. The same idea seems to have infected many libraries.

It's cause they have no standard library.

This means the attack can be "invisible", as a cursory glance at the output of the curl can be misleading.

You _have_ to curl with piping the output into a file (like | cat), and examine that file to detect any anomaly.

Those projects typically rely on an external package manager to handle their dependencies for them. Apt, yum, etc. Otherwise you end up in dependency hell trying to get ./configure to find the development headers of whatever it needs. I don't miss those days. Rust/Cargo is a godsend.

I think it would be hard to get any kind of usable capability system without algebraic effects like those of Koka or Scala libraries.

EDIT: Apparently Security Managers are deprecated and slated for removal.