3 ms·

> 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 wa

> 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-started-packaging?pivots=shell-cmd https://learn.microsoft.com/en-gb/vcpkg/get_started/get-star... [2]: https://learn.microsoft.com/en-gb/vcpkg/get_started/get-started-adding-to-registry?pivots=shell-cmd https://learn.microsoft.com/en-gb/vcpkg/get_started/get-star...

IshKebab 2y 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.
- delta_p_delta_x 2y 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.
  - IshKebab 2y 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.

IshKebab 2y 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.

delta_p_delta_x 2y 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.
- IshKebab 2y 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.