3 ms·

Wonderful post! I've written a couple of packager manager like things over the years. Although they've all been internal-only which gives some flexibility. > I

Wonderful post! I've written a couple of packager manager like things over the years. Although they've all been internal-only which gives some flexibility. > I like the idea of allowing both project and global scope Yikes! Hard no from me. Globals are pure evil. Avoid like the plague. Environment variables too. Kill them all with fire. > what if the user wants to reinstall the packages on another machine or CI server? That’s where the lockfile comes in I've typically bypassed the need for a lockfile by simply checking in the dependencies. Dependencies belong in version control! That's a rant for another day. Treating the packages folder as source of truth is basically the equivalent I think? > I understand that dropping dependencies altogether may not be something you are ready to accept. Nice. A corollary to this is that if all your packages are internal then you can simply disallow dependency graphs that want different versions of the same package. Simply bump and fix-up all version number dependencies for all packages. The basically means "all packages play nicely on latest version". Which when all the packages live in a monorepo is perfectly plausible. Totally doesn't work for public package managers, but that's a different story.

verdverm 3y ago
It totally works for Go with MVS, which bumps a lot of versions behind the scenes for you.
RajT88 3y ago
> Environment variables too. Kill them all with fire. I feel this way about host file entries. It is shocking how common they remain, and not just in QA/Dev.
nonameiguess 3y ago
> I've typically bypassed the need for a lockfile by simply checking in the dependencies. Dependencies belong in version control! These are binary dependencies. You're checking shared object files into source control? Note that he's also doing this to add functionality to a binary installation of sqlite, which is presumably running somewhere like /usr/bin/sqlite. This isn't a custom application he's developing. The extensions are in his home directory. "Checking them into version control" would entail making his entire filesystem a Git repo. If you're willing to pay whatever IBM charges these days for ClearCase, something like that might actually work. Regular source control like Git, though? I don't think so.
- forrestthewoods 3y ago
  Binaries absolutely should go in version control. The fact that Git is incapable of efficiently supporting that workflow is a separate topic.
  - seabass-labrax 3y ago
    I think you are right. Tarballs with version strings as filenames served from an HTTPD are effectively a poor man's version control. Git commits are immutable and efficient (storing only the delta) for text, but those same benefits could apply to binary files too if only the tooling was better. You may be interested to know that Debian actually does use Git to store binary data, although only when it is not possible to use the source files to generate the binary data directly.

verdverm 3y ago

It totally works for Go with MVS, which bumps a lot of versions behind the scenes for you.

RajT88 3y ago

> Environment variables too. Kill them all with fire. I feel this way about host file entries. It is shocking how common they remain, and not just in QA/Dev.

nonameiguess 3y ago

> I've typically bypassed the need for a lockfile by simply checking in the dependencies. Dependencies belong in version control! These are binary dependencies. You're checking shared object files into source control? Note that he's also doing this to add functionality to a binary installation of sqlite, which is presumably running somewhere like /usr/bin/sqlite. This isn't a custom application he's developing. The extensions are in his home directory. "Checking them into version control" would entail making his entire filesystem a Git repo. If you're willing to pay whatever IBM charges these days for ClearCase, something like that might actually work. Regular source control like Git, though? I don't think so.

forrestthewoods 3y ago
Binaries absolutely should go in version control. The fact that Git is incapable of efficiently supporting that workflow is a separate topic.
- seabass-labrax 3y ago
  I think you are right. Tarballs with version strings as filenames served from an HTTPD are effectively a poor man's version control. Git commits are immutable and efficient (storing only the delta) for text, but those same benefits could apply to binary files too if only the tooling was better. You may be interested to know that Debian actually does use Git to store binary data, although only when it is not possible to use the source files to generate the binary data directly.