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
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.
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.
(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.
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.
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.
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 :/
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.
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 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...
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 hn@ycombinator.com and we'll give you some tips about how to do it for best results.
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.
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.
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.
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.
- 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.
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.
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.
Translating commands from a generic command interface to specific commands is a great case for polymorphism.