Hacker News new | ask | show | jobs
by IshKebab 779 days ago
> more than half a decade out of date

Yes... but as great as vcpkg is, it's still not ubiquitous enough that everything is on it, in the same way that everything is available for Rust via Cargo, or for Python via pip, or for Java/typescript via NPM.

So submodules are still used quite a lot.
1 comments
delta_p_delta_x 779 days ago
> but as great as vcpkg is, it's still not ubiquitous enough that everything is on it

Completely fair assessment; I wanted to add MIT's krb5 and realised it wasn't on vcpkg.

> So submodules are still used quite a lot

And this is the wrong solution. The correct one would be to put in the leg-work and write a new portfile[1] and submit it as a PR[2].

[1]: https://learn.microsoft.com/en-gb/vcpkg/get_started/get-star...

[2]: https://learn.microsoft.com/en-gb/vcpkg/get_started/get-star...

link
IshKebab 779 days ago
> And this is the wrong solution. The correct one ...

This is not very realistic. I don't want to become a package maintainer of somebody else's library.

But I 100% agree that submodules are not good. I'm hoping Pijul will handle that sort of thing better but I haven't tried it.

link
delta_p_delta_x 779 days ago
> This is not very realistic. I don't want to become a package maintainer of somebody else's library.

Fair enough; then maybe ask the library developer nicely if they could add vcpkg support. Many C++ libraries de-facto support CMake and vcpkg because these have reached critical mass over the past half-decade or so.

I'd say submodules are worse in every metric—you still have to maintain someone else's library (imagine a CVE patch comes through, for instance); submodules themselves are so fragile that they can break your own repo, requiring a full delete + re-clone, and it leads to 'I have this code, I can now make changes to it' which makes updating even harder.

link
IshKebab 779 days ago
> you still have to maintain someone else's library (imagine a CVE patch comes through, for instance)

I wouldn't call `git pull` maintaining a library.

> it leads to 'I have this code, I can now make changes to it

I would say this is a big advantage! Probably one of the few areas where submodules are better than e.g. crates/pypi. It's great for fixing bugs for example. You can fix bugs in Rust crates you use, by using a special override in Cargo.toml, and I assume pip/NPM support that somehow took, but it is more of a pain.

You're absolutely right that submodules are fragile. But they work well enough that people still use them.

> requiring a full delete + re-clone

I've got pretty close to that but actually I've been able to get out of every submodules breakage that I got into. Did require some magic commands I found in a mailing list somewhere though which isn't fun.

I've had zero problems with stability though if you avoid these two features:

* Worktrees, which sucks because worktrees are great

* git checkout --recurse-submodules (or submodule.recurse). This is just fundamentally broken and has been forever.

link