If the project is useful for you and you’re happy with code and documentation: release it.

To be honest, there is a class of problems that are extremely common, like maintaining installations, deployment scripts, logging, argument parsing. Apparently you tool belongs to this “really common” problems.

There is also a class of people who tend to solve problems by programming, and prefer doing so before doing some sort of exhaustive research for existing solution. Apparently you belong to this class of people.

I love that this class of people is here (hey, I’m part of it!), having this creative mindset is superb for learning and growing, and for keeping it fun (that’s really important! it’s dangerous to go without fun!).

I say, if you really get joy from solving problems this way then definitely keep this. Perks of being in this “class” is that we often grow attached to our projects and watching it not succeed can be painful.

So just remember to not put all the eggs into one basket: it’s good to realize when you’re in a domain where lots of mature solutions exist so success requires (sans impossible luck) being way much better than the existing ones. Because it can mean that getting people to try out your solution can be disproportionately harder than it “should be” given quality of it. You might need to prepare yourself for a long season of being the only user. On the other hand, looking for beta testers or reviewers, can be a different thing.

Just to make clear, I don’t want this to sound discouraging in any way – it’s just personal experience and failure that might be good for others to not repeat.

I think the fact that, eg. on pypi there are tons of logging and argument parsing libraries shows the overlap between these classes of problems. Another thing is that most of these libraries is going to be abandoned. Again, I think that overall it’s a good way – it means that lots of people love coding and are trying – it’s humanity’s way of getting awesome things.

It doesn’t really matter if it’s usefull for others. Write it for yourself and learn from it. I myself wrote copying script for terminal and I am sure no one else going to use it just me and thats fine.

It would be easier for me to understand if you can explain how this is different from the various other methods of installing software onto a computer.

• How is this different from a package manager, or something like FlatPak or AppImage, where you can find scripts (not necessarily bash scripts) to install whole packages from a binary repository?
• How is this different from Nix or Guix, which provides a method of automatically setting up a shell environment with all dependencies ready for you to build a piece of software from its source code?
• Is there an advantage to your solution over something like OhMyZsh, which provides a repository of Zsh functions you can install to configure the Zsh user interface.
• Is there a reason why, if someone does not want to use a package manager, or Nix/Guix, they would prefer to use your solution rather than just go to the website and find the script there to install the software they need?