Live data from Hacker News

GitHub: sysget – A front-end for every package manager

github.com

41–50 of 64 posts

Re: GitHub: sysget – A front-end for every package manager

#41

C++ is an "interesting" language choice. I would have expected a bash script. Equally portable, and no hassle with compilation for different arch/OS.

The same author has previously implemented the same thing in Python, https://github.com/termget/termget . It's linked in the readme.

Re: GitHub: sysget – A front-end for every package manager

#42
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)

Re: GitHub: sysget – A front-end for every package manager

#43

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.

Re: GitHub: sysget – A front-end for every package manager

#44
post #40

I'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.

[deleted]

Re: GitHub: sysget – A front-end for every package manager

#45

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 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.

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.

Re: GitHub: sysget – A front-end for every package manager

#46
post #10

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,…

[deleted]

Re: GitHub: sysget – A front-end for every package manager

#49

I'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.

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).

Re: GitHub: sysget – A front-end for every package manager

#50

I'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.

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

Post reply on HN