@heiglandreas "Those aren't dependencies of your application. Just tools..."
Fair, but also, if I remove development dependencies from the my projects if they're just tools then those projects no longer have development dependencies.
Which I guess leads me to "what are development dependencies for if not things needed for development?"
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.
@tyx
It also happens with current packages. For example, it happens sometimes that changes on CRAN lead to package removals which pull others with them. I was affected by this. The maintainer just did not react fact enough (bunch of weeks).
@tyx Yeah, this is all very painful, but it is also not specific to R, or is it? I imagine most software have the same issue if you use external packages.
Btw. we do have some tools that let you "time-travel", e.g. https://packagemanager.posit.co/client/#/ gives you Linux binaries since 2017, or you can use Windows binaries even from CRAN.
Another one is https://github.com/r-hub/evercran which comes with daily CRAN snapshots, and works on older Debian containers, so you also get older versions of the system deps.
Anyone know how to install version 18.19 of nodejs in an Ubuntu instance in Github Actions? apt-get can't find that version. #help#linux#ubuntu#nodejs#dependencyHell
Rant: today I wanted to prepare a simple NFT demo for high-schoolers. They should use a pre-created smart contract, add their images, and then deploy this on a test network.
finding some test-EHT was already difficult
some tutorials exist, so I tried to follow those
eth-brownie doesn't seem to be supported anymore and doesn't work on MacOSX (anymore?)
it's successor, eth-ape, doesn't work on MacOSX, neither
I tried devbox (nix), docker, compiling from source... Usually I think of myself of a good programmer. But dependency hell in Python is a level I'm really not used to.
Anybody got any idea how to do this in a simple way?
Maven Central and Gradle Plugin Portal should have never allowed to publish dependencies with not-fixed versions.
If you don't check your transitives carefully, something might sneak in. And you have non-reproducible builds. Which you only notice once something breaks.
@jendrik Alternative take: build tools using those repos should have had "lockfiles" the moment they had version ranges, so you can get reproducible builds and have an easy way to update dependencies and declare version compatibility (Gradle has lockfiles, and rich versions; Maven lacks everything; I can't tell for other build tools)
@tbroyer There are features in tools to make builds still stable – locking, additional constraints, forced versions, dependency rules...
I just think there is no value in publishing an open range in a public repository.
Did you go to the future to check that future versions will still work? No? Then what does it even mean?
It may be different in a "closed world" (e.g. company repository) where you can make assumptions about future versions. But in the open, it has zero value IMO.