C++ is an "interesting" language choice. I would have expected a bash script. Equally portable, and no hassle with compilation for different arch/OS.
GitHub: sysget – A front-end for every package manager
41–50 of 64 posts
Re: GitHub: sysget – A front-end for every package manager
#42> 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)
Re: GitHub: sysget – A front-end for every package manager
#43C++ is an "interesting" language choice. I would have expected a bash script. Equally portable, and no hassle with compilation for different arch/OS.
I find it quite useful as I'm switching daily between Arch Linux, Ubuntu, and MacOS.
Re: GitHub: sysget – A front-end for every package manager
#44I'm curious why the author chose to put every command in its own file and then copy the big if tree with string compares in every file. Translating commands from a generic command interface to specific commands is a great case for polymorphism.
My guess is they didn't know better. That isn't the only amateurism in the code.
Re: GitHub: sysget – A front-end for every package manager
#45Some missing features: - Show version of an installed package - List content of package - Fix package (or reinstall?) - Install/Update history - Revert last install/update operation Unfortunately not all of these features are directly supported by all package managers. E.g. package contents for yum are `repoquery -l`. I have to google this every time. Real value in wrapping that in a simple command.
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.
Re: GitHub: sysget – A front-end for every package manager
#46I like this. This makes a lot of sense to me. If it managed to gain adoption into major distros, it would be incredibly good, though obviously that is a longshot for a lot of reasons. 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,…
Re: GitHub: sysget – A front-end for every package manager
#47Missing flatpak :(
Re: GitHub: sysget – A front-end for every package manager
#48Re: GitHub: sysget – A front-end for every package manager
#49I'm curious why the author chose to put every command in its own file and then copy the big if tree with string compares in every file. 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).
Re: GitHub: sysget – A front-end for every package manager
#50I'm curious why the author chose to put every command in its own file and then copy the big if tree with string compares in every file. Translating commands from a generic command interface to specific commands is a great case for polymorphism.
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