Hacker News Reader

Comment by reactordev | Hacker News Reader

This is horrible. Just use vcpkg or any number of other c++ package managers. Pypi exists for a reason. Maven and gradle exist for a reason. Nuget exists for a reason. NPM/Yarn as well.

Storing your dependencies with your code ensures you will be out of date, vulnerable to whatever vulnerabilities have been patched since then, and that your build will produce a different hash so windows defender will do a full binary scan on you every time. Not to mention an all-hands on deck weekend holiday to upgrade.

View on HN

> Storing your dependencies with your code ensures you will be out of date, vulnerable to whatever vulnerabilities have been patched since then

I missed the part where having a copy of the dependencies you last built with means that you are required to never ever ever make use of any bugfixes that have come out since the first time those dependencies were committed.

If you don't have automated management, you will probably not regularly check for updates on every one of dozens of dependencies manually.

Sorry, what? I genuinely can't understand what you're saying/talking about.

There's a John Cleese quote that comes to mind. What they are saying is, if your dependencies are manually checked in, are you going to be on top of keeping them up to date for all the sev-1 CVE's that are found? Patches that are backported? Bugs that are fixed? And keep them all in sync? If your answer is yes to any of these, go look up the John Cleese quote. That is, unless you have an army of devs and maintainers to do it and get paid for it (hi Red Hat!).

> if your dependencies are manually checked in, are you going to be on top of keeping them up to date for all the sev-1 CVE's that are found? Patches that are backported? Bugs that are fixed? And keep them all in sync?

Compared. To. What? (Alternatively: "uh... yes?")

This is something like the third time that I've had to confront a comment alluding to the idea that having dependencies checked in to your repo means that updating them becomes, through some unspecified means, extremely difficult. And not just difficult, but intractably difficult. How exactly? Who knows—I've asked, but all I get are the same sort of continual allusions, as if it's some forgone conclusion on which there is common agreement, or it's a self-evident truth or something, but the actual thought process behind the remarks remain as impenetrable as the first time it was said. Please show your work. Please.

What precisely is the mechanism by which this this is supposed to happen and that forms the basis for your position? What two things precisely are you comparing to one another? Be specific. Don't be vague.

This conversation shouldn't be this exasperatingly difficult to have.

The precise mechanism is that if your update mechanism involves a manual step per-dependency(You have manually copied and pasted things into your repo), then the time needed to check for updates will scale with the number of dependencies.

Manually checking all of them to even see what has updates available will take at least 10 to 20 minutes searching one by one. Likely up to several hours, even at 30 seconds per manual check.

The odds that laziness or tight schedules will take over and nobody ever actually does this are higher.

If one does actually do this, then they will be wasting 20 minutes regularly.

> The precise mechanism is that if your update mechanism involves a manual step per-dependency(You have manually copied and pasted things into your repo), then the time needed to check for updates will scale with the number of dependencies.

I don't know what you're referring to. The resolution up for debate is "Dependencies belong in version control". You seem to be having a totally different conversation (where you "manually copied and pasted things into your repo").

What "Dependencies belong in version control" means is:

- DO NOT add them to .gitignore.

- DO `git add` them just like any other code.

Updating things doesn't change; you update the packages that you depend on the same way you do if you aren't checking your dependencies in—e.g. by running `npm update` (or whatever).

True, if the language tooling supports that kind of workflow well, and you do it right then it should indeed be a different case.

Things like this SO thread seems to suggest manually copying dependencies is a somewhat common (bad ideaful) interpretation of the concept though:

https://softwareengineering.stackexchange.com/questions/3724...

You don't need special language tooling support. `git add` works regardless of which language you're using; we're shedding excessive tooling here (read: disentangling it from places it shouldn't be).

"Why prefer a package manager over a library folder?" is a false dichotomy. Package managers are still responsible for managing packages—when your dependencies are checked into the repo, the package manager just operates on the packages that are already on disk instead of fetching them in a separate step and/or at the very last minute and being intertwined with the build process.

It worked well for many years, but was really a time drain and in fact quite horrible.

I still have some JS code stashed right in the repo, but I think that should be fixed as part of a more comprehensive npm-ification.

There's lots of pretty much vanilla HTML/JS Mako templates, with a few one-page Vue applets, maybe it should all be ported to SvelteKit or just a proper Vue project, so there's a proper framework managing everything.

I didn't know c++ had general purpose package management now! I've only ever used C++ for embedded, where we've got PlatformIO(Which I love).

>"It worked well for many years"

Those years where the web was in it's infancy? Or the years prior to that of the PDP days? Because since the WWW, the industry has seen some serious growth. Not only in profits (yey) but in people (oh no!) and having to manage it all (what to do when there's two "pch.h"?). The problem reared its head in the Linux early days when trying to amalgamate everyone's patches and code into the monolith that is KERNEL. This is why git exists. Lessons learned from falling flat on our faces and having no solution but to come up with a solution (our best talent!).

However, we have amnesia. We forget what we did, let alone why we did it. So we are repeating ourselves, only this time it's amplified by Web 2.0 (3.0?), GitHub, OSS is cool, OSS is how to go from garage to Meta. So why do we balk at the idea of doing the same management to our source code repositories? Why must we have all the things in our repo to look at? Why can't we trust the ABI? There are legit reasons for these questions, however, saying "check everything into your repo, balloons and all" is not the way.

Trusting the ABI is not a thing when you don't have an ABI(Because you're not doing a compiled language) and any or all of your dependencies could make breaking changes (either accidentally or just for fun because devs like to tweak function names) at any moment.

Package management is great(For development, for release and distribution I greatly prefer static linking or things like snap packages or APKs that trust the OS and bring everything else included), but only because you can pin stuff.

Pinning is basically the same concept as checking everything in, except the repo doesn't physically hold the data, and you can update with automated tools.

Reply on news.ycombinator.com