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.
GitHub: sysget – A front-end for every package manager
11–20 of 64 posts
Re: GitHub: sysget – A front-end for every package manager
#12All it does is compare strings and shell out, should be written in something like Bash rather than C++.
I guess then they'd have to worry about Bash version (or whether Bash is there at all). 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.
Re: GitHub: sysget – A front-end for every package manager
#13All it does is compare strings and shell out, should be written in something like Bash rather than C++.
I guess then they'd have to worry about Bash version (or whether Bash is there at all). Why not Go? ;)
It could easily be written for any Bourne-compatible shell. A compiled language is overkill, and C++ is a security risk.
Re: GitHub: sysget – A front-end for every package manager
#14It 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.
[deleted]
Re: GitHub: sysget – A front-end for every package manager
#15It 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.
If it's stupid and it works, it ain't stupid.
Re: GitHub: sysget – A front-end for every package manager
#16It 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.
Re: GitHub: sysget – A front-end for every package manager
#17I'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.
Re: GitHub: sysget – A front-end for every package manager
#18Re: GitHub: sysget – A front-end for every package manager
#19Re: GitHub: sysget – A front-end for every package manager
#20It 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 pag…
(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.