Writing a Package Manager
antonz.org
Writing a Package Manager
1–10 of 106 posts
Re: Writing a Package Manager
#2Writing a package manager is not one of the most common programming tasks. After all, there are many out-of-the-box ones available.
Re: Writing a Package Manager
#3Writing a package manager is not one of the most common programming tasks. After all, there are many out-of-the-box ones available.
These copy-pasted one-liners aren't useful. Skip them.
Re: Writing a Package Manager
#4Wonderful 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.
Re: Writing a Package Manager
#5I 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 gaming or whatever. That way a breach of one doesn't necessarily end up pwning the whole system.
I only have two accounts, one "serious" and one "off hours" but I still feel better protected than most people.
Re: Writing a Package Manager
#6Man, I really wish frontend package management could be this simple, but with a system that ultimately ships bytes over the wire, we have to not only massage the dough with chopsticks (insofar as try to reduce our dependency tree with weak, feckless tools), but also, with the sheer number of transitive dependencies for each package addition, it’s almost impossible to really know what’s going on with your dependencies unless you write plug-in after plug-in.
Re: Writing a Package Manager
#7Wonderful 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…
> 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.
Re: Writing a Package Manager
#8Awesome post! I worked with a bunch of package managers over the years and one can see that this design got inspired by the hood parts of a few I know.
The only design part I don‘t really like is the ‚latest‘ version specifier in the spec file. Which moves the declaration what the latest version is to the hosted location (in the example GitHub via GitHub API) paired with the fact that the checksums are also fetched rather than being part of the spec. This makes no sense for me. The spec needs to be versioned or better the spec is the actual location to declare a release. I kind of understand where the desire comes from to have a floating spec. Makes the publish process easier since one only creates a GitHub release in this case. But I would still argue that explicitly creating a new version of the spec for each version with baked checksums is better. The benefit for me would be that one could create a hash for each spec version for instance and use that internally for instance.
Re: Writing a Package Manager
#9Writing 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".
Re: Writing a Package Manager
#10I 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 bit the bullet and ported hundreds of apps to a new, sandboxed environment in Linux, while attempting to upstream the whole effort. This would necessarily involve things like fully migrating to Wayland (X11 security is awful), only granting filesystem access through distro-sanctioned file pickers (so you need some coordination among Gtk, Qt, and other toolkits), and generally having a deny-by-default policy: first you make secure, then you fix what broke.