4 ms·

Seems like what all we would need on the VCS side is something like Git LFS but with global chunk based deduplication, binary file patching algorithms, which s

Seems like what all we would need on the VCS side is something like Git LFS but with global chunk based deduplication, binary file patching algorithms, which serves the actual files over bittorent. The last part is essential, because GitHub LFS is too expensive for anyone to just try out on their own. But then, on the dev tool side, we would need automated ways to get all that stuff in the repo in the first place, and make sure that the IDE linting and autocomplete knows about it. I used to put my python dependencies in a thirdparty folder, and have a line that alters the sys.path to point at it. I just spent a week getting rid of all that and using PyPi, because it didn't play nice with linters and I couldn't swap different versions of dependencies with virtualenv, updating required manual work, and there was no management to make sure there wasn't version conflicts in subtle ways. I like the idea of deps in VCS, but not as much as I like using tools as the devs intended and sticking to the official workflow everyone else uses.

reactordev 3y ago
This is horrible. Just use vcpkg or any number of other c++ package managers. Pypi exists for a reason. Maven and gradle exist for a reason. Nuget exists for a reason. NPM/Yarn as well. Storing your dependencies with your code ensures you will be out of date, vulnerable to whatever vulnerabilities have been patched since then, and that your build will produce a different hash so windows defender will do a full binary scan on you every time. Not to mention an all-hands on deck weekend holiday to upgrade.
- cxr 3y ago
  > Storing your dependencies with your code ensures you will be out of date, vulnerable to whatever vulnerabilities have been patched since then I missed the part where having a copy of the dependencies you last built with means that you are required to never ever ever make use of any bugfixes that have come out since the first time those dependencies were committed.
  - eternityforest 3y ago
    If you don't have automated management, you will probably not regularly check for updates on every one of dozens of dependencies manually.
    - cxr 3y ago
      Sorry, what? I genuinely can't understand what you're saying/talking about.
      - reactordev 3y ago
        There's a John Cleese quote that comes to mind. What they are saying is, if your dependencies are manually checked in, are you going to be on top of keeping them up to date for all the sev-1 CVE's that are found? Patches that are backported? Bugs that are fixed? And keep them all in sync? If your answer is yes to any of these, go look up the John Cleese quote. That is, unless you have an army of devs and maintainers to do it and get paid for it (hi Red Hat!).
        cxr 3y ago
        > if your dependencies are manually checked in, are you going to be on top of keeping them up to date for all the sev-1 CVE's that are found? Patches that are backported? Bugs that are fixed? And keep them all in sync? Compared. To. What? (Alternatively: "uh... yes?") This is something like the third time that I've had to confront a comment alluding to the idea that having dependencies checked in to your repo means that updating them becomes, through some unspecified means, extremely difficult. And not just difficult, but intractably difficult. How exactly? Who knows—I've asked, but all I get are the same sort of continual allusions, as if it's some forgone conclusion on which there is common agreement, or it's a self-evident truth or something, but the actual thought process behind the remarks remain as impenetrable as the first time it was said. Please show your work. Please. What precisely is the mechanism by which this this is supposed to happen and that forms the basis for your position? What two things precisely are you comparing to one another? Be specific. Don't be vague. This conversation shouldn't be this exasperatingly difficult to have.
- eternityforest 3y ago
  It worked well for many years, but was really a time drain and in fact quite horrible. I still have some JS code stashed right in the repo, but I think that should be fixed as part of a more comprehensive npm-ification. There's lots of pretty much vanilla HTML/JS Mako templates, with a few one-page Vue applets, maybe it should all be ported to SvelteKit or just a proper Vue project, so there's a proper framework managing everything. I didn't know c++ had general purpose package management now! I've only ever used C++ for embedded, where we've got PlatformIO(Which I love).
  - reactordev 3y ago
    >"It worked well for many years" Those years where the web was in it's infancy? Or the years prior to that of the PDP days? Because since the WWW, the industry has seen some serious growth. Not only in profits (yey) but in people (oh no!) and having to manage it all (what to do when there's two "pch.h"?). The problem reared its head in the Linux early days when trying to amalgamate everyone's patches and code into the monolith that is KERNEL. This is why git exists. Lessons learned from falling flat on our faces and having no solution but to come up with a solution (our best talent!). However, we have amnesia. We forget what we did, let alone why we did it. So we are repeating ourselves, only this time it's amplified by Web 2.0 (3.0?), GitHub, OSS is cool, OSS is how to go from garage to Meta. So why do we balk at the idea of doing the same management to our source code repositories? Why must we have all the things in our repo to look at? Why can't we trust the ABI? There are legit reasons for these questions, however, saying "check everything into your repo, balloons and all" is not the way.
    - eternityforest 3y ago
      Trusting the ABI is not a thing when you don't have an ABI(Because you're not doing a compiled language) and any or all of your dependencies could make breaking changes (either accidentally or just for fun because devs like to tweak function names) at any moment. Package management is great(For development, for release and distribution I greatly prefer static linking or things like snap packages or APKs that trust the OS and bring everything else included), but only because you can pin stuff. Pinning is basically the same concept as checking everything in, except the repo doesn't physically hold the data, and you can update with automated tools.

reactordev 3y ago

This is horrible. Just use vcpkg or any number of other c++ package managers. Pypi exists for a reason. Maven and gradle exist for a reason. Nuget exists for a reason. NPM/Yarn as well. Storing your dependencies with your code ensures you will be out of date, vulnerable to whatever vulnerabilities have been patched since then, and that your build will produce a different hash so windows defender will do a full binary scan on you every time. Not to mention an all-hands on deck weekend holiday to upgrade.

cxr 3y ago
> Storing your dependencies with your code ensures you will be out of date, vulnerable to whatever vulnerabilities have been patched since then I missed the part where having a copy of the dependencies you last built with means that you are required to never ever ever make use of any bugfixes that have come out since the first time those dependencies were committed.
- eternityforest 3y ago
  If you don't have automated management, you will probably not regularly check for updates on every one of dozens of dependencies manually.
  - cxr 3y ago
    Sorry, what? I genuinely can't understand what you're saying/talking about.
    - reactordev 3y ago
      There's a John Cleese quote that comes to mind. What they are saying is, if your dependencies are manually checked in, are you going to be on top of keeping them up to date for all the sev-1 CVE's that are found? Patches that are backported? Bugs that are fixed? And keep them all in sync? If your answer is yes to any of these, go look up the John Cleese quote. That is, unless you have an army of devs and maintainers to do it and get paid for it (hi Red Hat!).
      - cxr 3y ago
        > if your dependencies are manually checked in, are you going to be on top of keeping them up to date for all the sev-1 CVE's that are found? Patches that are backported? Bugs that are fixed? And keep them all in sync? Compared. To. What? (Alternatively: "uh... yes?") This is something like the third time that I've had to confront a comment alluding to the idea that having dependencies checked in to your repo means that updating them becomes, through some unspecified means, extremely difficult. And not just difficult, but intractably difficult. How exactly? Who knows—I've asked, but all I get are the same sort of continual allusions, as if it's some forgone conclusion on which there is common agreement, or it's a self-evident truth or something, but the actual thought process behind the remarks remain as impenetrable as the first time it was said. Please show your work. Please. What precisely is the mechanism by which this this is supposed to happen and that forms the basis for your position? What two things precisely are you comparing to one another? Be specific. Don't be vague. This conversation shouldn't be this exasperatingly difficult to have.
eternityforest 3y ago
It worked well for many years, but was really a time drain and in fact quite horrible. I still have some JS code stashed right in the repo, but I think that should be fixed as part of a more comprehensive npm-ification. There's lots of pretty much vanilla HTML/JS Mako templates, with a few one-page Vue applets, maybe it should all be ported to SvelteKit or just a proper Vue project, so there's a proper framework managing everything. I didn't know c++ had general purpose package management now! I've only ever used C++ for embedded, where we've got PlatformIO(Which I love).
- reactordev 3y ago
  >"It worked well for many years" Those years where the web was in it's infancy? Or the years prior to that of the PDP days? Because since the WWW, the industry has seen some serious growth. Not only in profits (yey) but in people (oh no!) and having to manage it all (what to do when there's two "pch.h"?). The problem reared its head in the Linux early days when trying to amalgamate everyone's patches and code into the monolith that is KERNEL. This is why git exists. Lessons learned from falling flat on our faces and having no solution but to come up with a solution (our best talent!). However, we have amnesia. We forget what we did, let alone why we did it. So we are repeating ourselves, only this time it's amplified by Web 2.0 (3.0?), GitHub, OSS is cool, OSS is how to go from garage to Meta. So why do we balk at the idea of doing the same management to our source code repositories? Why must we have all the things in our repo to look at? Why can't we trust the ABI? There are legit reasons for these questions, however, saying "check everything into your repo, balloons and all" is not the way.
  - eternityforest 3y ago
    Trusting the ABI is not a thing when you don't have an ABI(Because you're not doing a compiled language) and any or all of your dependencies could make breaking changes (either accidentally or just for fun because devs like to tweak function names) at any moment. Package management is great(For development, for release and distribution I greatly prefer static linking or things like snap packages or APKs that trust the OS and bring everything else included), but only because you can pin stuff. Pinning is basically the same concept as checking everything in, except the repo doesn't physically hold the data, and you can update with automated tools.