GitHub is almost forever. Your custom domain disappears when you stop paying the bills, which if you’re an open source developer has a higher likelihood than GitHub disappearing.
One day, we’re all going back to vendoring dependencies.
Updates mean you have to copy over all the code into your repo, which creates a large diff, and hope you aren't overwriting any local changes someone might have made.
It bloats your repo, both with the actual code, and the large diffs when you update it.
You have to manually track new versions, without something to tell you if new versions are available, or if your version has known security vulnerabilities.
If the dependency has it's own dependencies, you have to vendor those too recursively. And if multiple dependencies have the same transitive dependency, it is up to you to deduplicate them, and make sure you have a version compatible with all dependents.
If I want to upgrade the disk on my MacBook Pro, I need to buy a new MacBook Pro with a larger disk. If I want to upgrade the disk on my work laptop, I’m SOL.
> Ensuring that diffs to updated dependencies remain within a vendor folder is trivial.
It’s not obvious to me how putting the dependencies in a vendor folder solves the diff problem. Does every code host allow you to hide diffs to certain directories?
And what’s the advantageous scenario for vendored dependencies? Is it just when the mod proxy and the upstream code host go down at the same time?
> If I want to upgrade the disk on my MacBook Pro, I need to buy a new MacBook Pro with a larger disk
Is this a significant risk in reality? MBPs today come with a minimum of 1TB of storage. Even 5 years ago I think the minimum was 256 GB. This is more than large enough for all but the most massive repositories, even with vendored dependencies. And you can always plug in external SSDs or HDDs or connect to a network server.
> And what’s the advantageous scenario for vendored dependencies? Is it just when the mod proxy and the upstream code host go down at the same time?
This is a useful homework assignment. Ask your favorite LLM or consult some respected release engineering books. Also consult your local AppSec and infosec teams.
> This is more than large enough for all but the most massive repositories
Consider the possibility that the drive needs to accommodate more than just a single repository?
I have lots of software, entire language toolchains, AI models, Docker images, application volumes, VMs, etc.
And this isn’t a theoretical concern; I have to free up space every few months.
> This is a useful homework assignment. Ask your favorite LLM or consult some respected release engineering books. Also consult your local AppSec and infosec teams.
So there is no advantage scenario that you’re aware of?
SenHeng · · focus · HN ↗
One day, we’re all going back to vendoring dependencies.
otterley · · focus · HN ↗
metaltyphoon · · focus · HN ↗
otterley · · focus · HN ↗
thayne · · focus · HN ↗
It bloats your repo, both with the actual code, and the large diffs when you update it.
You have to manually track new versions, without something to tell you if new versions are available, or if your version has known security vulnerabilities.
If the dependency has it's own dependencies, you have to vendor those too recursively. And if multiple dependencies have the same transitive dependency, it is up to you to deduplicate them, and make sure you have a version compatible with all dependents.
Etc.
otterley · · focus · HN ↗
Recursive dependencies have the same issues whether you vend them or not.
Ensuring that diffs to updated dependencies remain within a vendor folder is trivial.
So, what’s left?
throwaway894345 · · focus · HN ↗
If I want to upgrade the disk on my MacBook Pro, I need to buy a new MacBook Pro with a larger disk. If I want to upgrade the disk on my work laptop, I’m SOL.
> Ensuring that diffs to updated dependencies remain within a vendor folder is trivial.
It’s not obvious to me how putting the dependencies in a vendor folder solves the diff problem. Does every code host allow you to hide diffs to certain directories?
And what’s the advantageous scenario for vendored dependencies? Is it just when the mod proxy and the upstream code host go down at the same time?
otterley · · focus · HN ↗
Is this a significant risk in reality? MBPs today come with a minimum of 1TB of storage. Even 5 years ago I think the minimum was 256 GB. This is more than large enough for all but the most massive repositories, even with vendored dependencies. And you can always plug in external SSDs or HDDs or connect to a network server.
> And what’s the advantageous scenario for vendored dependencies? Is it just when the mod proxy and the upstream code host go down at the same time?
This is a useful homework assignment. Ask your favorite LLM or consult some respected release engineering books. Also consult your local AppSec and infosec teams.
throwaway894345 · · focus · HN ↗
Consider the possibility that the drive needs to accommodate more than just a single repository?
I have lots of software, entire language toolchains, AI models, Docker images, application volumes, VMs, etc.
And this isn’t a theoretical concern; I have to free up space every few months.
> This is a useful homework assignment. Ask your favorite LLM or consult some respected release engineering books. Also consult your local AppSec and infosec teams.
So there is no advantage scenario that you’re aware of?
otterley · · focus · HN ↗
throwaway894345 · · focus · HN ↗