81–90 of 106 posts
Source control is my package manager. Package managers as we usually think of them are syntax sugar and abstraction for the sake of abstraction Working on a Linux distro that is one unified/generalized/normalized code base (with the help of AI/ML) and a model to sample and establish correct state from memory of the initial code base. One way to think of it is like a game engine with action plans to allocate resources…
Writing a package manager is not one of the most common programming tasks. After all, there are many out-of-the-box ones available.
Imagine what'd we be using for package management today if package manager >= #2 author said "you know what, one already exists".
Earlier quoted context omitted.
Use Bazel.
I’ve heard a lot about Bazel but are there any good beginner tutorials? When I last looked it felt a little Nix-like (high learning curve to get through which I prefer to ignore for my tooling where possible)
Bit of a tangent here but what’s a pip/npm/cargo like package manager for C++? For example ‘pip install boost’? I’ve never worked it out for hobby projects and never worked with it commercially
Pip does not attempt to resolve dependency conflicts of already installed packages, only the ones it is currently trying to install. Nor does it try to manage the life cycle of installed packages, such as removing transitive dependencies never specified or no longer needed or create consistent environments with a lock file.
As package specifications have become better defined (rather than "whatever setup.py does") and are being better enforced (e.g. Pip will soon reject version numbers that are non-compliant) there are several attempts at writing full-fledged package managers (Rye, Huak, Pixi, etc.) and I'm sure once one of them gains critical mass it will replace Pip quickly.
Earlier quoted context omitted.
You want to bring in a dependency to avoid writing one 8 line CTE?
The number of lines needed is not a good measure for gnarliness. (To be fair, I don't know if gnarliness is measurable at all.)
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…
> 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 e…
Source control is my package manager. Package managers as we usually think of them are syntax sugar and abstraction for the sake of abstraction Working on a Linux distro that is one unified/generalized/normalized code base (with the help of AI/ML) and a model to sample and establish correct state from memory of the initial code base. One way to think of it is like a game engine with action plans to allocate resources…
I think some day rather than the current paradigm, even including declarative package managers and environments and distros, the future will be per-user and even per-app chrooting or jails, or something similar. Apple already uses something like this today. Many people who are smart about information security have one login for shopping and banking and bill pay, one for their business, and one for cruising the web or…
> Apple already uses something like this today Some Linux distros too have things like this but unfortunately there is no buy-in across the ecosystem so "sandboxing" is done in a half-baked way. The problem is when applications in general aren't written with sandboxing in mind, and when you have to choose between apps not working properly or having a leaky sandbox, you will opt for the latter. I wish some big corp bi…
Personally, I am not so sure about Flathub (the 'official' repository for Flatpak bundles), but Flatpak itself is a welcome (and large) step towards universal sandboxing for desktop applications.
[1]: https://www.spinics.net/lists/fedora-devel/msg312784.html
Earlier quoted context omitted.
> 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 e…
Binaries absolutely should go in version control. The fact that Git is incapable of efficiently supporting that workflow is a separate topic.