upvote
I always force myself to do this too. The only 3rd party python library I regularly use is "requests" basically —a dependency that comes with its own baggage, see the recent controversy about "chardet"— but I go out of my way to grab it from pip instead installing it via pip. :-)

Something like this:

    try:
        import requests
    except ImportError:
        from pip._vendor import requests
reply
This is good wisdom, and I think this is a strong reason why language and runtime developers should ensure their standard library is (over)complete.

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.

reply
Is this a win for .NET where the mothership provides almost all what you need?
reply
.NET is great because you use a FOSS library and then a month later the developer changes the licence and forces you to either pay a subscription for future upgrades or swap it out.
reply
Yeah why is this so common in .NET?
reply
Enterprise usage. Devs know companies will just pay out. Easier than trying to get sponsored.
reply
Definitely!

The amount of third-party (non-testing related) dependencies needed for most .NET applications is very manageable and the dependencies themselves (generally) don't come with further third-party dependencies (especially now that JSON serialisation is native).

This means that for most applications, the developers know exactly which dependencies are needed (and they are not hidden away in large folder structures either, the dlls are right next to the assembly).

reply
C#/.NET is a good example showing no matter how much programmers you have, how much capital you hold, it's still impossible to make a 'batteries-included' ecosystems because the real world is simply too vast.
reply
Say what you want but I can write a production backend without any non-Microsoft dependencies. Everything from db and ORM to HTTP pipeline/middleware to json serialization to auth to advanced logging (OTel). Yes, sometimes we opt for 3rd party packages for advanced scenarios but those are few and far between, as opposed to npm/js where the standard library is small and there is little OOTB tooling and your choices are to reinvent a complex wheel or depend on a package that can be exploited. I argue the .NET model is winning the new development ecosystem.
reply
I agree with you, almost all .NET code I write is within the .NET framework, yet when I look at C# repos, it's disheartening to see so many (new) projects just NuGet this NuGet that.

We have text.json now but I still see people use Newtonsoft JSON.

There's old repo's out there that should be archived and deprecated, yet I see new games use it when the repo is very questionable with automated whitespace or comment commits to keep up the appearance that it is still being maintained[0].

Right now I'm working on a Golang project and the dependency tree is a nightmare to say the least, I hope to be able to rip out the parts I don't need and compile it without the massive bulk that I do not need.

It's very frustrating to want me to trust the author, who trust the author, who trust the author. When I doubt they even audited or looked at what they imported.

[0] https://github.com/sta/websocket-sharp

reply
I'm not a fan of that ecosystem, but you make a good point. I wish JS had more basic utilities built in.
reply
and the pendulum swings again the other way...
reply
Does it? Or is it simply different people
reply
I generally limit myself to what's available in my distribution, if the standard library doesn't provide it. But normally I never use requests because it's not worth it I think to have an extra dependency.
reply
This might hold true for easy deps, but (let's be honest who would install is promise) if you have complex or domain specific stuff and you don't have the time to do yourself or the std lib does not have anything then yeh you might still fall into the pit, or you have to trust that the library does not have an supply chain chain issue itself.
reply
But then you rely on Python, C, your editor with all its extensions etc.

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!

reply
> I go out of my way to avoid using external packages.

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.

reply
HTMX > Live View
reply
Sure, if that works for you, then great.
reply