Search
61 results for “dependencyhell”
-
@gnu0os0ta @RonRevog @mozilla @ManjaroARM Würde schon sagen, dass *keine* Arch-basierte Distro für Einsteiger zu empfehlen ist. Wenn irgendetwas schief geht, ist man sehr, sehr schnell in der #dependencyhell.
Mint oder Ubuntu mag man belächeln (würde ich ja auch nicht mehr nehmen), aber das ist ja genau der Punkt.
-
CW: re: Current status
-
It was just an angle for the story. Pretty sure cooling water needs electricity for the pumps.
-
Had to dive into someone else’s old, abandoned project today to grab some screenshots.
Nothing like trying to lubricate the cogs of a Next.js 8, React 16 site from 6 years ago and all its dependencies to get it back into motion again.
The wonders of dependency rot.
-
#DependencyHell with its #security & #maintenance implications are an issue with *any* system (e.g. #NPM, #Maven, etc.) that makes adding dependencies frictionless.
#Go proverb: “A little copying is better than a little dependency.” (https://go-proverbs.github.io/)
-
One brief note: when David says the "new way" is to use Python virtual environments, that's extremely relative. It has been best practice (and the only way to save your sanity because of dependency hell in any nontrivial project) in the Python community for, I dunno, 20 years? But Python's been around for >30, so it is the "new" way. Long before the `virtualenv` tool I was accomplishing the same thing with symlink trees to isolate interpreters.
There are lots of opinions on where you should keep your venvs, i.e. what the path to them should be. I personally like putting them in the project directory, typically `<project>/.venv`, but others like to stash them away someplace, like in ~/.local/share. Project tools that handle virtualenv management (e.g. poetry, uv, etc) will generally give you a way to control where they create the venvs.
-
There’s one thing that consistently showed up in my work as a software engineer over the decades. Spaghetti.
Spaghetti code is easier to write than maintain, and in doing software archaeology (yes, it’s a thing), I’ve encountered numerous reasons for it. Requirements creep is one of the largest reasons.
In fact, the first real software archaeology I did was explained, proudly, as being a product of someone walking in and telling the developer, “Wouldn’t it be nice if…”. Of course, nobody wrote anything down, and by the time I got to it the software was 25 years old and didn’t even have a brochure. People were still walking in and saying, “Wouldn’t it be nice if…”. Meanwhile, the company was required to follow standard software processes because it was required for contracts.
So I learned, from good teachers and a few bad ones, about Software Configuration Management, Software Quality Assurance, and Software Testing. There were reasons we did things a certain way. Our project configuration management contained everything needed to rewrite the software from scratch, including every single tool. I’d actually done a backup of a development pc after writing down the hardware specifications of the system and handed that in because quality assurance had to be able to take the same stuff and rebuild the same software so that it could be tested.
From scratch. And it had to pass the same tests. From scratch.
What I saw in other companies after that was never at that level, and on the surface it seemed ridiculous. However, any software engineer worth their weight in skittles has been screwed over by a platform changing underneath the code. Windows was infamous for it, though I did encounter it in an Apple shop as well. Your code hasn’t changed, but some update suddenly had you in the middle of bug city without even a flip flop. Microsoft has been notorious about that, with their version back in the day called DLL Hell. It’s just their (old) version of dependency hell.
I never had the problem with *nix systems, though when open source became popular and everyone started using that in their code, *nix systems started to get it too. People blamed the open source, but it was really 2 things that caused the problem.
(1) Bad Configuration Management (if it even existed!) and
(2) Taking the open source project for granted.Open Source projects that are done voluntarily are completely outside the control of a company, but having an open dialog and even sending some money for pizzas and beer can avoid issues. Even with all of that, volunteers are fickle, so having in house expertise on projects becomes as important as how important the projects are to a company’s software. A company doesn’t really know this, though, when they don’t have software configuration management for their projects – so you end up with spaghetti projects, or as I call it, “Spaghetti Configuration Management”.
Toss in the developers that are copying and pasting from Stack Overflow, or now GPT, dash in employee turnover, where expertise is lost, and you get software entropy. Talking about software entropy causes the eyes of pointy haired bosses to roll to the back of their heads, so instead we talk about technical debt, because one thing businesses understand is debt.
Over the years, companies I worked for were at various stages of technical debt. It’s a real thing, and the startups that survived long enough to get to the point of technical debt were the worst because of the culture shift needed: Documenting things, tracking things, and making sure that the knowledge stayed within the company. I can say with good conscience that I left every company better off than when I left it, sometimes because of the company, sometimes despite the company.
So we get to the article, “Hidden Tech Debt: The Importance Of Better Updates For Commercial Software“, which I came across through the author on Mastodon. It tackles the one thing I didn’t write about here: commercial software dependencies and lack of accountability in that, which is a bigger problem than we might think.
https://knowprose.com/2024/04/20/spaghetti-source-spaghetti-dependencies/
#dependencyHell #SCM #softwareArchaeology #softwareEngineering #softwareEntropy #softwareRot #spaghettiCode #SQA #technicalDebt #Technology
-
There’s one thing that consistently showed up in my work as a software engineer over the decades. Spaghetti.
Spaghetti code is easier to write than maintain, and in doing software archaeology (yes, it’s a thing), I’ve encountered numerous reasons for it. Requirements creep is one of the largest reasons.
In fact, the first real software archaeology I did was explained, proudly, as being a product of someone walking in and telling the developer, “Wouldn’t it be nice if…”. Of course, nobody wrote anything down, and by the time I got to it the software was 25 years old and didn’t even have a brochure. People were still walking in and saying, “Wouldn’t it be nice if…”. Meanwhile, the company was required to follow standard software processes because it was required for contracts.
So I learned, from good teachers and a few bad ones, about Software Configuration Management, Software Quality Assurance, and Software Testing. There were reasons we did things a certain way. Our project configuration management contained everything needed to rewrite the software from scratch, including every single tool. I’d actually done a backup of a development pc after writing down the hardware specifications of the system and handed that in because quality assurance had to be able to take the same stuff and rebuild the same software so that it could be tested.
From scratch. And it had to pass the same tests. From scratch.
What I saw in other companies after that was never at that level, and on the surface it seemed ridiculous. However, any software engineer worth their weight in skittles has been screwed over by a platform changing underneath the code. Windows was infamous for it, though I did encounter it in an Apple shop as well. Your code hasn’t changed, but some update suddenly had you in the middle of bug city without even a flip flop. Microsoft has been notorious about that, with their version back in the day called DLL Hell. It’s just their (old) version of dependency hell.
I never had the problem with *nix systems, though when open source became popular and everyone started using that in their code, *nix systems started to get it too. People blamed the open source, but it was really 2 things that caused the problem.
(1) Bad Configuration Management (if it even existed!) and
(2) Taking the open source project for granted.Open Source projects that are done voluntarily are completely outside the control of a company, but having an open dialog and even sending some money for pizzas and beer can avoid issues. Even with all of that, volunteers are fickle, so having in house expertise on projects becomes as important as how important the projects are to a company’s software. A company doesn’t really know this, though, when they don’t have software configuration management for their projects – so you end up with spaghetti projects, or as I call it, “Spaghetti Configuration Management”.
Toss in the developers that are copying and pasting from Stack Overflow, or now GPT, dash in employee turnover, where expertise is lost, and you get software entropy. Talking about software entropy causes the eyes of pointy haired bosses to roll to the back of their heads, so instead we talk about technical debt, because one thing businesses understand is debt.
Over the years, companies I worked for were at various stages of technical debt. It’s a real thing, and the startups that survived long enough to get to the point of technical debt were the worst because of the culture shift needed: Documenting things, tracking things, and making sure that the knowledge stayed within the company. I can say with good conscience that I left every company better off than when I left it, sometimes because of the company, sometimes despite the company.
So we get to the article, “Hidden Tech Debt: The Importance Of Better Updates For Commercial Software“, which I came across through the author on Mastodon. It tackles the one thing I didn’t write about here: commercial software dependencies and lack of accountability in that, which is a bigger problem than we might think.
https://knowprose.com/2024/04/20/spaghetti-source-spaghetti-dependencies/
#dependencyHell #SCM #softwareArchaeology #softwareEngineering #softwareEntropy #softwareRot #spaghettiCode #SQA #technicalDebt #Technology
-
There’s one thing that consistently showed up in my work as a software engineer over the decades. Spaghetti.
Spaghetti code is easier to write than maintain, and in doing software archaeology (yes, it’s a thing), I’ve encountered numerous reasons for it. Requirements creep is one of the largest reasons.
In fact, the first real software archaeology I did was explained, proudly, as being a product of someone walking in and telling the developer, “Wouldn’t it be nice if…”. Of course, nobody wrote anything down, and by the time I got to it the software was 25 years old and didn’t even have a brochure. People were still walking in and saying, “Wouldn’t it be nice if…”. Meanwhile, the company was required to follow standard software processes because it was required for contracts.
So I learned, from good teachers and a few bad ones, about Software Configuration Management, Software Quality Assurance, and Software Testing. There were reasons we did things a certain way. Our project configuration management contained everything needed to rewrite the software from scratch, including every single tool. I’d actually done a backup of a development pc after writing down the hardware specifications of the system and handed that in because quality assurance had to be able to take the same stuff and rebuild the same software so that it could be tested.
From scratch. And it had to pass the same tests. From scratch.
What I saw in other companies after that was never at that level, and on the surface it seemed ridiculous. However, any software engineer worth their weight in skittles has been screwed over by a platform changing underneath the code. Windows was infamous for it, though I did encounter it in an Apple shop as well. Your code hasn’t changed, but some update suddenly had you in the middle of bug city without even a flip flop. Microsoft has been notorious about that, with their version back in the day called DLL Hell. It’s just their (old) version of dependency hell.
I never had the problem with *nix systems, though when open source became popular and everyone started using that in their code, *nix systems started to get it too. People blamed the open source, but it was really 2 things that caused the problem.
(1) Bad Configuration Management (if it even existed!) and
(2) Taking the open source project for granted.Open Source projects that are done voluntarily are completely outside the control of a company, but having an open dialog and even sending some money for pizzas and beer can avoid issues. Even with all of that, volunteers are fickle, so having in house expertise on projects becomes as important as how important the projects are to a company’s software. A company doesn’t really know this, though, when they don’t have software configuration management for their projects – so you end up with spaghetti projects, or as I call it, “Spaghetti Configuration Management”.
Toss in the developers that are copying and pasting from Stack Overflow, or now GPT, dash in employee turnover, where expertise is lost, and you get software entropy. Talking about software entropy causes the eyes of pointy haired bosses to roll to the back of their heads, so instead we talk about technical debt, because one thing businesses understand is debt.
Over the years, companies I worked for were at various stages of technical debt. It’s a real thing, and the startups that survived long enough to get to the point of technical debt were the worst because of the culture shift needed: Documenting things, tracking things, and making sure that the knowledge stayed within the company. I can say with good conscience that I left every company better off than when I left it, sometimes because of the company, sometimes despite the company.
So we get to the article, “Hidden Tech Debt: The Importance Of Better Updates For Commercial Software“, which I came across through the author on Mastodon. It tackles the one thing I didn’t write about here: commercial software dependencies and lack of accountability in that, which is a bigger problem than we might think.
https://knowprose.com/2024/04/20/spaghetti-source-spaghetti-dependencies/
#dependencyHell #SCM #softwareArchaeology #softwareEngineering #softwareEntropy #softwareRot #spaghettiCode #SQA #technicalDebt #Technology
-
Who else is in @gentoo #Python #DependencyHell right now?
-
That problems origin probably lies somewhere else:
#npm #dependency #overkill #dependencyhell #overuse -
Spent half a day trying to resurrect an old (as in: working fine, has not needed significant changes in the recent years) pet project using Node.js.
I was neither able to build the project with latest node, nor setting up an environment with the last working Node version (12) and install dependencies with that.
Currently trying to modernize the build toolchain, which is an even bigger time sink. Seriously considering adding node_modules to source control.
-
CW: rant
Now installing #actix comes with 175 dependencies…
Really not a fan of that either, especially given the generally alpha-state of the ecosystem, but let’s see…
#DependencyHell -
Are npm packages and dependencies an unmitigated disaster, or is it just me?
-
Ah, the masochist's guide to "How to Waste Your Life Compiling a Glorified Toaster" has hit version 12.3! 🎉 Because who needs a life when you can spend weeks in dependency hell, right? Surely, Gerard and Bruce's secret life mission is to ensure no one actually uses a computer for, you know, computing. 🔧💻
https://www.linuxfromscratch.org/lfs/view/12.3/ #masochistsguide #dependencyhell #softwaredevelopment #glorifiedtoaster #computinglife #HackerNews #ngated -
🤣 Ah yes, the age-old question: can an #AI compile code even older than the average TikTok user? 🕰️ Apparently, we're supposed to be impressed that our digital overlords are now tackling 'dependency hell'—because nothing screams innovation like revisiting your grandpa's #coding nightmares. 🔧💥
https://quesma.com/blog/introducing-compilebench/ #DependencyHell #DigitalOverlords #TechHumor #RetroCoding #HackerNews #ngated -
Is there anybody out there, running an #EndeavourOS development system with Rust, DotNet, Qt, Angular, Elixir, Brave and is able of updating w/o error? Could that person perhaps show me how to do it?? #ArchLinux #DependencyHell
-
tandis que le CRAN organise la cohérence entre les différentes versions de ses packages, ce travail d'alignement fait malheureusement défaut dans Pypi, raison pour laquelle Bruno Rodrigues plaide pour un meilleur contrôle des packages dans PyPi sous l'aspect de leur interopérabilité avec les autres packages qu'il contient https://brodrigues.co/posts/2025-08-22-pypan.html #Pypi #CRAN #DependencyHell
-
Not unique to #Rust with #Cargo:
“Rust Dependencies Scare Me”, Vincent Sgherzi (https://vincents.dev/blog/rust-dependencies-scare-me/).
Via Lobsters: https://lobste.rs/s/j3nhhc/rust_dependencies_scare_me
On HN: https://news.ycombinator.com/item?id=43935067
#DependencyHell #Dependencies #Security #Reuse #Maintenance #SoftwareEngineering
-
You don't need a framework or a tool,
You need a mirror in this dependency-driven development.Simplicity is the key. But instead, many are choosing a janitor's life.
Gluing dependencies like it's glitter on a kindergarten project.
It’s not that AI struggles with simplicity. It just learned it from you.Developers today worship frameworks like ancient cults, adding layers, tools, plugins, and just a sprinkle of hope. A microservice? No. It's a monolith in disguise. 10,000 custom lines of over-abstracted ceremony just to say "Hello, World".
We summon demons. And each dependency is a pact we don't read before signing. Scary, we understand more of the framework than of our programming language.
Today, I wrote a chatbot. 100 lines. Pure Java. No feign, no Eureka, no YAML in sight. It compiles to a native executable. It runs. It lives. It doesn't cry at night. It will stay forever. No .sdkmanrc, no dependabot, no excuses, never legacy.
The more tools you add, the more you suffer. Onboarding grows, maintenance creeps, code rots, metadata multiplies… and actual work quietly leaves the room.
Good services run in the background without much maintenance. No bugs, no Incidents and nearly forgotten.
Don't Keep debating the fastest library while the glue makes it slow anyway.
The real costs are humans. Slow, expensive, and prone to burnout.
Not the €200/Month for 20 more bloated zoo of extra instances.#JavaWithoutCrying
#KillTheGlue
#DependencyHell
#SimplicityFirst
#CodeMinimalism
#MicroserviceMadness
#FrameworkCult
#CeremonialCode
#LegacyProof
#DevRealTalk
#BurnTheYAML
#OnboardingNightmare
#CodeOverConfig
#NoExcusesCode
#AIReflectsUs
#SoftwareSins
#TheRealTechDebt
#LeanCodeWins
#Coding
#programming -
Who knows why I see `rustc` running when I run `pip install --no-binary :all: --no-compile jsonschema`?
Shouldn't that be avoided because I said "do not compile"?
Edit: I was using these options in the hope to get an overview of binary vs. pure-Python packages.
-
🚨 When your code is a few KB, but your dependencies rival AAA game installations. Still believe in fairy tales of secure code?
Gigabytes of code you didn't write. Licences you didn't read. Security flaws you didn't anticipate. Yet, you trust them. Adorable.
Not just Node.js. Gradle caches, AWS libs with 400 sub-dependencies + reflection parties. In control? How cute.
I use plain Java with jlink + jpackage. Minimal. Secure. No bloat.
Fewer deps = fewer surprises. Because I care.
But hey, keep stacking that Jenga tower. Watching it fall will be fun.
#MinimalismMatters #CleanCode #DependencyHell #JavaPurist #DoYouEvenCare #LessIsMore #CodeSmart #TechDebt #DependencyManagement #JavaDeveloper #SecureCoding #LightweightCode #ModernJava #RefactorYourLife #NoBloat #CodeQuality #developer #code
-
🚨 When your code is a few KB, but your dependencies rival AAA game installations. Still believe in fairy tales of secure code?
Gigabytes of code you didn't write. Licences you didn't read. Security flaws you didn't anticipate. Yet, you trust them. Adorable.
Not just Node.js. Gradle caches, AWS libs with 400 sub-dependencies + reflection parties. In control? How cute.
I use plain Java with jlink + jpackage. Minimal. Secure. No bloat.
Fewer deps = fewer surprises. Because I care.
But hey, keep stacking that Jenga tower. Watching it fall will be fun.
#MinimalismMatters #CleanCode #DependencyHell #JavaPurist #DoYouEvenCare #LessIsMore #CodeSmart #TechDebt #DependencyManagement #JavaDeveloper #SecureCoding #LightweightCode #ModernJava #RefactorYourLife #NoBloat #CodeQuality #developer #code
-
🚨 When your code is a few KB, but your dependencies rival AAA game installations. Still believe in fairy tales of secure code?
Gigabytes of code you didn't write. Licences you didn't read. Security flaws you didn't anticipate. Yet, you trust them. Adorable.
Not just Node.js. Gradle caches, AWS libs with 400 sub-dependencies + reflection parties. In control? How cute.
I use plain Java with jlink + jpackage. Minimal. Secure. No bloat.
Fewer deps = fewer surprises. Because I care.
But hey, keep stacking that Jenga tower. Watching it fall will be fun.
#MinimalismMatters #CleanCode #DependencyHell #JavaPurist #DoYouEvenCare #LessIsMore #CodeSmart #TechDebt #DependencyManagement #JavaDeveloper #SecureCoding #LightweightCode #ModernJava #RefactorYourLife #NoBloat #CodeQuality #developer #code
-
🚨 When your code is a few KB, but your dependencies rival AAA game installations. Still believe in fairy tales of secure code?
Gigabytes of code you didn't write. Licences you didn't read. Security flaws you didn't anticipate. Yet, you trust them. Adorable.
Not just Node.js. Gradle caches, AWS libs with 400 sub-dependencies + reflection parties. In control? How cute.
I use plain Java with jlink + jpackage. Minimal. Secure. No bloat.
Fewer deps = fewer surprises. Because I care.
But hey, keep stacking that Jenga tower. Watching it fall will be fun.
#MinimalismMatters #CleanCode #DependencyHell #JavaPurist #DoYouEvenCare #LessIsMore #CodeSmart #TechDebt #DependencyManagement #JavaDeveloper #SecureCoding #LightweightCode #ModernJava #RefactorYourLife #NoBloat #CodeQuality #developer #code
-
🚂📦 "Cargo-rail" claims to be the ultimate #monorepo tool for #Rust, but with 11 dependencies, it seems more like a dependency-rail! 😂 #GitHub wants you to believe it's like the Swiss Army knife of code, but really it's just a butter knife dressed up in a tuxedo. 🍴👔
https://github.com/loadingalias/cargo-rail #CargoRail #DependencyHell #Humor #CodeTools #HackerNews #ngated -
“Package Managers Are Evil”, Bill “GingerBill” Hall (https://www.gingerbill.org/article/2025/09/08/package-managers-are-evil/).
On HN: https://news.ycombinator.com/item?id=45167394
On Lobsters: https://lobste.rs/s/zvdtdn/package_managers_are_evil
#Programming #Packages #Dependencies #DependencyHell #PackageManagers #Rants #DependencyManagement
-
“Package Managers Are Evil”, Bill “GingerBill” Hall (https://www.gingerbill.org/article/2025/09/08/package-managers-are-evil/).
On HN: https://news.ycombinator.com/item?id=45167394
On Lobsters: https://lobste.rs/s/zvdtdn/package_managers_are_evil
#Programming #Packages #Dependencies #DependencyHell #PackageManagers #Rants #DependencyManagement
-
“Package Managers Are Evil”, Bill “GingerBill” Hall (https://www.gingerbill.org/article/2025/09/08/package-managers-are-evil/).
On HN: https://news.ycombinator.com/item?id=45167394
On Lobsters: https://lobste.rs/s/zvdtdn/package_managers_are_evil
#Programming #Packages #Dependencies #DependencyHell #PackageManagers #Rants #DependencyManagement
