GitHub: sysget – A front-end for every package manager
github.com
github.com
Translating commands from a generic command interface to specific commands is a great case for polymorphism.
It is simple, it works, everyone can understand the code and update it.
That is actually very valuable, especially for a project like this which tends to need maintenance to keep alive (whenever some wrapped command changes).
It means all logic for a specific package manager is gathered in one place instead of spread out over many files and the compiler can prevent us making stupid mistakes like forgetting to add a subcommand or mistyping the packagename in the big if/if/if statement.
In the current implementation we have (X = numberOfPMs*numberOfCommands) string compares which are not checked by the compiler. That means X potential typo's that each need a unit test just to verify that the implementation is hooked up correctly.
I would say that a class based implementation like this is simpler and prevents more errors during maintenance than the current version.
Don't put down OOP and classes just because hating on GoF patterns is all the rage in 2018, they exist for a reason. This is a clear case for applying them.
The one change I would suggest is putting the package manager names as constants all in one place. That way, you can't make a typo in one of the checks in the if statements. That, and maybe replacing the if-else chain with a switch statement. Might help remove some duplication
Who cares it's a hacked together small program with if statements? It's not any less interesting than a proposal for a new standard in a 50 page PDF document to me.
(2) Package names aren't always identical across platforms, at least not enough that you can rely on that.
It is a low-cost attempt to solve a problem that in my opinion doesn't really exist and it doesn't even do a great job doing that due to the points above.
For instance if you want to use pacman without knowing what -Ss stands for, at the slightest conflict, you'll be going back to using pacman without this wrapper.
Perhaps people who need to have package managers abstracted away could be a good target for Docker. Maybe a web UI to dynamically bake a docker image with required packages.
The fact that everything is different makes it a problem worth solving. Docker just abstracts the problem.
For me the problem this tool solves is real (although not big), and I'm interested to see what other people think of both the problem and the solution. That's why I upvoted it, I guess other people had similar ideas.
I haven't encountered this for all the standard applications I end up installing on my machines (things like htop, nginx, etc).
> What problem does it solve?
It solves the problem of me having to think about what OS I am on before I can install something (and if it's something I don't use a lot I might need to google the package manager syntax).
When I need to do package management, I'll use a package manager. But for when I need to quickly install one tool to get something done, my giant shell function "ji" (stands for "just install") has saved me precious time.
In its current state, this project is equivalent to a bunch of command alises, but that doesn't mean it can't be useful.
If your job is to automate things and you're not using containers, then you're doing it wrong.
I find it quite useful as I'm switching daily between Arch Linux, Ubuntu, and MacOS.
> GitHub: sysget – A front-end for every package manager (github.com)
Right now, it seems like it is GitHub's own project when it's just hosted on GitHub.
It should be:
> Show HN: sysget – A front-end for every package manager (github.com)
Topgrade [1] upgrades all packages including distribution package managers (such as Homebrew, APT, DNF, ...), language specific package managers (such as Cargo, NPM, Gem, ...), program specific package managers (such as Vim, Tmux, shells, ...), Flatpak/Snap, working on The Big Three (Windows, Linux, macOS).
I wish there was a way to update Steam and Battle.net from the CLI as well.
If you really want it to get adopted into major distros, the best approach is probably to convince the systemd folks that it would be a great addition to their package ;)
edit: A bit of constructive criticism. I really like the concept, but I think the way that package managers are supported could be improved. I think it would be better if all of the handlers for a given package manager were in the same file, instead of having them spread across every file. There's obviously lots of ways to accomplish this.
Also, as it is now, this project does not seem to use a ton of things that require C++ - you could shave some binary size cost by converting it to pure C.
Why not Go? ;)
Meanwhile, C++ runtime almost definitely is going to exist on most bootstrapping images, so it's a lot easier to justify its inclusion - the cost of the C++ is greatly amortized.
Just a thought, what if you allowed it to run in different modes, for people used to different systems? apt mode, yum mode, pacman mode etc to accept commands in that format.
I’d be happy to learn a new syntax if that was the last time I had to deal with it.
- Show version of an installed package
- List content of package
- Fix package (or reinstall?)
- Install/Update history
- Revert last install/update operation
The reason is that I only want features that are supported by the most package managers. Sometimes you get a message that the package manager does not support this (especially chromebrew). I don't want to add features that only works with 2 or 3 package managers. I only want features that should work with every package manager. At the moment there are only essential tools. However I will try to add as many as possible.
pkcon is a good tool, even if a bit janky, that hides well lots of the differences between the several package managers it supports.
(I much prefer pacman's interface over trying to remember which of dpkg/apt-get/apt-policy to use etc., similarly rpm/dnf)
What happens when multiple package managers provide the same package?