GitHub: sysget – A front-end for every package manager(github.com)
github.com
GitHub: sysget – A front-end for every package manager
https://github.com/emilengler/sysget?files=1
63 comments
That bothered me at first, but thinking about it more, I actually don't mind it in such a small project for one reason:
I'd expected that at least 95% of first-year programming students could jump in and add support for a new package manager without any trouble.
By contrast, none of the students in my 3rd-year Java class could do the same in a version implemented with polymorphism.
This is the perfect project to get new programmers excited about contributing to open source.
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
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
I don't really see what this program would gain from an "enterprise fizzbuzz" implementation.
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 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).
Adding polymorphism for easier maintenance does not mean "enterprise fizzbuzz". I'm talking about one 1 abstract class to define the interface and 1 implementation class per package manager. That's N+1 classes (N = # of package managers).
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.
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.
I think the best point for class implementation you mention is to have all the related stuff in one place. That convinces me most =)
It seems nowadays people just upvote based on just the title. This is a switch statement wrapper around package managers, on the front-page of HN.
It's not always about the complexity of the solution. This is a great example of something annoying a lot of people here can identify with (myself included). I'd say this annoys a lot of people whose job it is to automate things, and this is the first proposed solution I see.
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.
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.
(1) There are many flags to these commands that you will need to know on a per platform basis anyway.
(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.
(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.
I started something like this. Your second reason is why I stopped. The additional layer creates more problems than it solves.
I don't see this as a replacement for knowing package manager syntax. As someone who works with many machines running many different distros at the same time, I appreciate being able to open a terminal and run "install htop", without using even a single brain cell to think about which distro it's running and instead focus on doing whatever I need to do (which is often time-sensitive).
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.
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.
Yes, abstractions do leak sometimes. I'm not saying I'm running this on all my production servers right now.
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.
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.
What problem does it solve? Just use the package manager provided by the platform...right? Especially given the problem of package naming, it’s different even between Debian and Ubuntu :/
> Especially given the problem of package naming
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).
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).
How common is this? I use 2.5 different package managers day-to-day (homebrew/pacman/pakku) and a few more occasionally (portage/pkg/apt). I can't really think of a situation where I had to really think about what I was running to install something. I'd imagine a scenario in which you're often dropped into a box you don't usually interact with would typically also come with a more homogenous environment as far as operating systems go.
It's not very common for me. I maintain a few boxes at different hosting providers for different projects that have been running for a long time. Sometimes I ssh in and update everything. Right now I have to google everytime I ssh into a centos box because I keep forgetting the yum syntax.
Don’t let perfect be the enemy of good (or bad, in this case).
The fact that everything is different makes it a problem worth solving. Docker just abstracts the problem.
The fact that everything is different makes it a problem worth solving. Docker just abstracts the problem.
But it often turns out there is more complexity in the problem that is ignored/forgotten in the solution. So the solution seems simple and complete at first but can never gain adoption beyond all but the most basic use cases, so it ends up useless as a standard.
> I'd say this annoys a lot of people whose job it is to automate things, and this is the first proposed solution I see.
If your job is to automate things and you're not using containers, then you're doing it wrong.
If your job is to automate things and you're not using containers, then you're doing it wrong.
You sound like someone who hasn't had Docker shit itself and lose track of a container's data which you then had to find and manually migrate...
No, that didn't happen to me, because I know what I'm doing and how Docker works. I used it since AUFS days.
[deleted]
If it's stupid and it works, it ain't stupid.
It doesn’t work. Different distributions and OSes use different names for packages.
Packages installed from different distros will conflict all over the place, this is silly, please don't add conda despite my other comment!
It also swallows command-line options.
C++ is an "interesting" language choice. I would have expected a bash script. Equally portable, and no hassle with compilation for different arch/OS.
I wrote this little thing in bash: https://github.com/vinc/pkg
I find it quite useful as I'm switching daily between Arch Linux, Ubuntu, and MacOS.
I find it quite useful as I'm switching daily between Arch Linux, Ubuntu, and MacOS.
I also have a wrapper that I also wrote in Bash that is also called pkg and also does short commands (pkg i <name>). And here I thought I was being clever...
So it means it's a good idea!
The same author has previously implemented the same thing in Python, https://github.com/termget/termget . It's linked in the readme.
I am the author.
I did not created TermGet, I'm just a developer of it.
TermGet works different then sysget.
TermGet is an console based interface where sysget only works with system arguments which is way more efficent.
I am the author of TermGet. TermGet is sort of like TermGet, but it has an interface. I wanted to make TermGet a cross platform software center for you terminal. I am only 13, and school has made it hard for me to find time for development, so TermGet development has slowed down. When I do have time TermGet is my favorite project to work on, and I'm probably not going to discontinue it until I run out of features to add. I need more feature ideas because TermGet has so many features, I'm running out of ideas.
Welcome to HN! You should post your work as a Show HN and ask the community for ideas. If you'd like to, email us at [email protected] and we'll give you some tips about how to do it for best results.
Exactly! I was expecting python or go.
The title of the submission is a bit misleading:
> 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)
> 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)
Is packagekit completely dead and forgotten these days?
Not in the GUI world. I believe both KDE Discover and GNOME Software use it, but I haven't seen it used on the command line. I wonder why...
That's not nearly "every package manager".
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.
[1] https://github.com/r-darwish/topgrade
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.
[1] https://github.com/r-darwish/topgrade
I 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, 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.
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.
[deleted]
All it does is compare strings and shell out, should be written in something like Bash rather than C++.
This kind of task is exactly what good old Perl was designed for.
I guess then they'd have to worry about Bash version (or whether Bash is there at all).
Why not Go? ;)
Why not Go? ;)
Love Go, but here's a good reason: This would make a cool piece of software for inclusion on the base system. Go produces relatively large binaries (for good reasons of course) and therefore it would probably be harder to ship.
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.
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.
It could easily be written for any Bourne-compatible shell. A compiled language is overkill, and C++ is a security risk.
[deleted]
Seems like a cool idea!
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.
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 think this would make it needlessly complex. The idea is to have it be the same everywhere.
I’d be happy to learn a new syntax if that was the last time I had to deal with it.
I’d be happy to learn a new syntax if that was the last time I had to deal with it.
Some missing features:
- Show version of an installed package
- List content of package
- Fix package (or reinstall?)
- Install/Update history
- Revert last install/update operation
Disclaimer:
I am the guy who made this
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.
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.
... why not PackageKit?
pkcon is a good tool, even if a bit janky, that hides well lots of the differences between the several package managers it supports.
pkcon is a good tool, even if a bit janky, that hides well lots of the differences between the several package managers it supports.
Some configuration management tools already abstract package managers. For example: https://puppet.com/docs/puppet/6.0/type.html#package.
There is also https://github.com/icy/pacapt
(I much prefer pacman's interface over trying to remember which of dpkg/apt-get/apt-policy to use etc., similarly rpm/dnf)
(I much prefer pacman's interface over trying to remember which of dpkg/apt-get/apt-policy to use etc., similarly rpm/dnf)
On the surface this looks like a useful project. If you plan to use it, do yourself a favor and avoid looking at the source code.
How does this handle edge cases like needing to run 'brew link' etc. occasionally?
What happens when multiple package managers provide the same package?
What happens when multiple package managers provide the same package?
A look at the source code shows that it decides what package manager it should use by using a config file, and to install a package it runs system("brew install asdf") so I guess you would see a message telling you to run 'brew link' from the homebrew output.
A wrapper around emerge? Nope...
Where's conda?
Obligatory xkcd: https://xkcd.com/1654/
Translating commands from a generic command interface to specific commands is a great case for polymorphism.