9 ms·

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

55 points by nathandaly 8y ago

slimsag 8y ago
How does this handle edge cases like needing to run 'brew link' etc. occasionally? What happens when multiple package managers provide the same package?
- orangea 8y ago
  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.
berbec 8y ago
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.
- Aeolun 8y ago
  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.
knocte 8y ago
Missing flatpak :(
- emilengler 8y ago
  Coming soon :)
deleted 8y ago
[deleted]
anothergoogler 8y ago
All it does is compare strings and shell out, should be written in something like Bash rather than C++.
- voltagex_ 8y ago
  I guess then they'd have to worry about Bash version (or whether Bash is there at all). Why not Go? ;)
  - jchw 8y ago
    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.
  - anothergoogler 8y ago
    It could easily be written for any Bourne-compatible shell. A compiled language is overkill, and C++ is a security risk.
- mcilloni 8y ago
  This kind of task is exactly what good old Perl was designed for.
jchw 8y ago
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.
- deleted 8y ago
  [deleted]
therein 8y ago
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.
- deleted 8y ago
  [deleted]
- phoe-krk 8y ago
  If it's stupid and it works, it ain't stupid.
  - sneak 8y ago
    It doesn’t work. Different distributions and OSes use different names for packages.
    - anothergoogler 8y ago
      It also swallows command-line options.
    - RayDonnelly 8y ago
      Packages installed from different distros will conflict all over the place, this is silly, please don't add conda despite my other comment!
- askmike 8y ago
  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.
  - therein 8y ago
    (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.
vbsteven 8y ago
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.
- akx 8y ago
  My guess is they didn't know better. That isn't the only amateurism in the code.
  - deleted 8y ago
    [deleted]
- xaedes 8y ago
  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).
  - vbsteven 8y ago
    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.
zokier 8y ago
Is packagekit completely dead and forgotten these days?
- franga2000 8y ago
  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...
unhammer 8y ago
There is also https://github.com/icy/pacapt 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)
vbernat 8y ago
Some configuration management tools already abstract package managers. For example: https://puppet.com/docs/puppet/6.0/type.html#package https://puppet.com/docs/puppet/6.0/type.html#package.
RayDonnelly 8y ago
Where's conda?
mcilloni 8y ago
... 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.
heinrichhartman 8y ago
C++ is an "interesting" language choice. I would have expected a bash script. Equally portable, and no hassle with compilation for different arch/OS.
- sush99 8y ago
  Exactly! I was expecting python or go.
- akx 8y ago
  The same author has previously implemented the same thing in Python, https://github.com/termget/termget https://github.com/termget/termget . It's linked in the readme.
  - emilengler 8y ago
    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.
    - pizzalovingnerd 8y ago
      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.
      - dang 8y ago
        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 hn@ycombinator.com and we'll give you some tips about how to do it for best results.
heinrichhartman 8y ago
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.
- emilengler 8y ago
  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.
Fnoord 8y ago
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 https://github.com/r-darwish/topgrade
another-cuppa 8y ago
A wrapper around emerge? Nope...
hkdobrev 8y ago
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)
anticensor 8y ago
Obligatory xkcd: https://xkcd.com/1654/ https://xkcd.com/1654/
alexeiz 8y ago
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.

55 points by nathandaly 8y ago

How does this handle edge cases like needing to run 'brew link' etc. occasionally? What happens when multiple package managers provide the same package?

orangea 8y ago
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.

berbec 8y ago

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.

Aeolun 8y ago
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.

knocte 8y ago

Missing flatpak :(

emilengler 8y ago
Coming soon :)

deleted 8y ago

[deleted]

anothergoogler 8y ago

All it does is compare strings and shell out, should be written in something like Bash rather than C++.

voltagex_ 8y ago
I guess then they'd have to worry about Bash version (or whether Bash is there at all). Why not Go? ;)
- jchw 8y ago
  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.
- anothergoogler 8y ago
  It could easily be written for any Bourne-compatible shell. A compiled language is overkill, and C++ is a security risk.
mcilloni 8y ago
This kind of task is exactly what good old Perl was designed for.

jchw 8y ago

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.

deleted 8y ago
[deleted]

therein 8y ago

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.

deleted 8y ago
[deleted]
phoe-krk 8y ago
If it's stupid and it works, it ain't stupid.
- sneak 8y ago
  It doesn’t work. Different distributions and OSes use different names for packages.
  - anothergoogler 8y ago
    It also swallows command-line options.
  - RayDonnelly 8y ago
    Packages installed from different distros will conflict all over the place, this is silly, please don't add conda despite my other comment!
askmike 8y ago
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.
- therein 8y ago
  (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.

vbsteven 8y ago

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.

akx 8y ago
My guess is they didn't know better. That isn't the only amateurism in the code.
- deleted 8y ago
  [deleted]
xaedes 8y ago
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).
- vbsteven 8y ago
  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.

zokier 8y ago

Is packagekit completely dead and forgotten these days?

franga2000 8y ago
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...

unhammer 8y ago

There is also https://github.com/icy/pacapt 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)

vbernat 8y ago

Some configuration management tools already abstract package managers. For example: https://puppet.com/docs/puppet/6.0/type.html#package https://puppet.com/docs/puppet/6.0/type.html#package.

RayDonnelly 8y ago

Where's conda?

mcilloni 8y ago

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

heinrichhartman 8y ago

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

sush99 8y ago
Exactly! I was expecting python or go.
akx 8y ago
The same author has previously implemented the same thing in Python, https://github.com/termget/termget https://github.com/termget/termget . It's linked in the readme.
- emilengler 8y ago
  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.
  - pizzalovingnerd 8y ago
    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.
    - dang 8y ago
      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 hn@ycombinator.com and we'll give you some tips about how to do it for best results.

heinrichhartman 8y ago

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.

emilengler 8y ago
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.

Fnoord 8y ago

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 https://github.com/r-darwish/topgrade

another-cuppa 8y ago

A wrapper around emerge? Nope...

hkdobrev 8y ago

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)

anticensor 8y ago

Obligatory xkcd: https://xkcd.com/1654/ https://xkcd.com/1654/

alexeiz 8y ago

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.