2 ms·
Many projects vendor code whose styles are not compatible. For C# this is common in Unity3D development. Often external dependencies, vendored, need custom patc
by an_opabinia 6y ago
Many projects vendor code whose styles are not compatible. For C# this is common in Unity3D development. Often external dependencies, vendored, need custom patches, future updates and are not available in VCS. Besides Git is ill-suited for vendoring.
Next you’ll say “all code should not be vendored.”
Anyway it’s interesting to disseminate opinions on style because agreement on style beyond the boundaries of a corporate engineering hierarchy is really the best route to solving style issues.
- acoard 6y agoJust create a `vendor/` folder and an exclude rule to your linters. Or for Unity include your `Assets/Scripts` folder, whichever fits better. >Besides Git is ill-suited for vendoring. VCS is ill suited for vendoring, but is there a better option? Vendoring is usually a "hack" in some ways as you're keeping dependancies local when you don't "have to", but if your goal is to keep 'em local then git does a fine job. I'm surprised to see push-back for this idea because I've never come across this stumbling block. Please feel free to disagree, as I feel like there might be a perspective I'm not considering or something I can learn.
- tikhonj 6y agoThis is one of the reasons I like the Nix package manager—I can use Nix to de facto vendor dependencies (at least in the sense of having a local copy where I fully control the version we're on) without the attendant Git/build tool/etc hassle. If anything, a Nix derivation with a hash is going to be more reliable than a git commit hash even when you control the repo because it forces the build of your vendored dependency (including any transitive dependencies) to be deterministic. The downside, of course, is that it can be a lot of effort to retrofit deterministic builds on top of external codebases not built with that in mind...