Live data from Hacker News

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

github.com

51–60 of 64 posts

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

#51
post #20
post #16

Earlier quoted context omitted.

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

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.

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

#52
post #29
post #16

Earlier quoted context omitted.

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…

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

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

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

#53
post #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.

I also have a wrapper that I also wrote in Bash that is also called pkg and also does short commands (pkg i ). And here I thought I was being clever...

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

#54
post #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.

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.

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

#56
post #37
post #28

Earlier quoted context omitted.

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

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.

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

#57
post #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).

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.

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

#58
post #29

Earlier quoted context omitted.

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

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.

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

#59
post #43

Earlier quoted context omitted.

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 also have a wrapper that I also wrote in Bash that is also called pkg and also does short commands (pkg i ). And here I thought I was being clever...

So it means it's a good idea!

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

#60
post #37

Earlier quoted context omitted.

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

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

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.
Post reply on HN