4 ms·

I’d like a package manager that essentially does a git clone, and a culture that says: “use very few dependencies, commit their source code in your repo, and re

I’d like a package manager that essentially does a git clone, and a culture that says: “use very few dependencies, commit their source code in your repo, and review any changes when you do an update.” That would be a big improvement to the modern package management fiasco.

hardwaregeek 1y ago
That’s called the original Go package manager and it was pretty terrible
- christophilus 1y ago
  I think it was only terrible because the tooling wasn't great. I think it wouldn't be too terribly hard to build a good tool around this approach, though I admittedly have only thought about it for a few minutes. I may try to put together a proof of concept, actually.
  - jerf 1y ago
    If you're working in Go, you don't need to put together a proof of concept. Very basic project tooling in conjunction with "go mod vendor", which takes care of copying in the dependencies in locally, will do what you're talking about. Go may not default to this operation, but using it this way is fairly easy.
hvb2 1y ago
Is that realistic though? What you're proposing is letting go of abstractions completely. Say you need compression, you're going to review changes in the compression code? What about encryption, a networking library, what about the language you're using itself? That means you need to be an expert on everything you run. Which means no one will be building anything non trivial.
- 3036e4 1y ago
  Small, trivial, things, each solving a very specific problem, and that can be fully understood, sounds pretty amazing though. Much better than what we have now.
  - hvb2 1y ago
    That's what a package is supposed to solve, no? Sure there are packages trying to solve 'the world' and as a result come with a whole lot of dependencies, but isn't that on whoever installs it to check? My point was that git clone of the source can't be the solution, or you own all the code... And you can't. You always depend on something....
    - 3036e4 1y ago
      Your dependencies are also part of your product and your full responsibility. No one you deliver a product to will accept "it wasn't my code, it was in a dependency of one of my dependencies" as an excuse. Of course you need to depend on things, but it is insane to not keep that to a minimum.
      - hvb2 1y ago
        So you're expecting to see every product affected by this to go and do a big mea culpa because one of their dependencies broke? Like how xz was attacked, everyone pointed at that and no one said they didn't vet their dependencies. That's the whole point, you attack a dependency that everyone relies on because it's been good and stable. That's how these pyramids build up over time. So spoiler, it's not unlikely one of the dependencies in your minimal set gets exploited...
        jen20 1y ago
        > So you're expecting to see every product affected by this to go and do a big mea culpa because one of their dependencies broke? Yes, absolutely. It's the bare minimum for people offering commercial products.
k3nx 1y ago
That what I used git submodules for. I had a /lib folder in my project where the dependencies were pulled/checked out from. This was before I was doing CI/CD and before folks said git submodules were bad. Personally, I loved it. I only looked and updating them when I was going to release a new version of my program. I could easily do a diff to see what changed. I might not have understood everything, but it wasn't too difficult to see 10-100 line code changes to get a general idea. I thought it was better than the big black box we currently deal with. Oh, this package uses this package, and this package... what's different? No idea now, really.
willsmith72 1y ago
sounds like the best way to miss critical security upgrades
- skydhash 1y ago
  That’s why most mature (as in disciplined) projects have a rss feed or a mailing list. So you know when there’s a security bug and what to do about it.
- christophilus 1y ago
  Why? If you had a package manager tell you "this is out of date and has vulnerability XYZ", you'd do a "gitpkg update" or whatever, and get the new code, review it, and if it passes review, deploy it.

hardwaregeek 1y ago

That’s called the original Go package manager and it was pretty terrible

christophilus 1y ago
I think it was only terrible because the tooling wasn't great. I think it wouldn't be too terribly hard to build a good tool around this approach, though I admittedly have only thought about it for a few minutes. I may try to put together a proof of concept, actually.
- jerf 1y ago
  If you're working in Go, you don't need to put together a proof of concept. Very basic project tooling in conjunction with "go mod vendor", which takes care of copying in the dependencies in locally, will do what you're talking about. Go may not default to this operation, but using it this way is fairly easy.

hvb2 1y ago

Is that realistic though? What you're proposing is letting go of abstractions completely. Say you need compression, you're going to review changes in the compression code? What about encryption, a networking library, what about the language you're using itself? That means you need to be an expert on everything you run. Which means no one will be building anything non trivial.

3036e4 1y ago
Small, trivial, things, each solving a very specific problem, and that can be fully understood, sounds pretty amazing though. Much better than what we have now.
- hvb2 1y ago
  That's what a package is supposed to solve, no? Sure there are packages trying to solve 'the world' and as a result come with a whole lot of dependencies, but isn't that on whoever installs it to check? My point was that git clone of the source can't be the solution, or you own all the code... And you can't. You always depend on something....
  - 3036e4 1y ago
    Your dependencies are also part of your product and your full responsibility. No one you deliver a product to will accept "it wasn't my code, it was in a dependency of one of my dependencies" as an excuse. Of course you need to depend on things, but it is insane to not keep that to a minimum.
    - hvb2 1y ago
      So you're expecting to see every product affected by this to go and do a big mea culpa because one of their dependencies broke? Like how xz was attacked, everyone pointed at that and no one said they didn't vet their dependencies. That's the whole point, you attack a dependency that everyone relies on because it's been good and stable. That's how these pyramids build up over time. So spoiler, it's not unlikely one of the dependencies in your minimal set gets exploited...
      - jen20 1y ago
        > So you're expecting to see every product affected by this to go and do a big mea culpa because one of their dependencies broke? Yes, absolutely. It's the bare minimum for people offering commercial products.

k3nx 1y ago

That what I used git submodules for. I had a /lib folder in my project where the dependencies were pulled/checked out from. This was before I was doing CI/CD and before folks said git submodules were bad. Personally, I loved it. I only looked and updating them when I was going to release a new version of my program. I could easily do a diff to see what changed. I might not have understood everything, but it wasn't too difficult to see 10-100 line code changes to get a general idea. I thought it was better than the big black box we currently deal with. Oh, this package uses this package, and this package... what's different? No idea now, really.

willsmith72 1y ago

sounds like the best way to miss critical security upgrades

skydhash 1y ago
That’s why most mature (as in disciplined) projects have a rss feed or a mailing list. So you know when there’s a security bug and what to do about it.
christophilus 1y ago
Why? If you had a package manager tell you "this is out of date and has vulnerability XYZ", you'd do a "gitpkg update" or whatever, and get the new code, review it, and if it passes review, deploy it.