TekWizely

I made a task runner inspired by make's simplicity but purpose-built for running tasks:

Run: Task runner that helps you easily manage and invoke small scripts and wrappers.

https://github.com/TekWizely/run

Do you find yourself using tools like make to manage non-build-related scripts?

Build tools are great, but they are not optimized for general script management.

Run aims to be better at managing small scripts and wrappers, while incorporating a familiar make-like syntax.

TekWizely here (creator of the linked project) - I didn't create this post but thanks to OP for sharing.

Happy to answer any Qs.

Also, I'm about to add a killer feature that lets each template tag provide a printf specifier to format values beyond the simple '%s' (current default).

Thanks again !

-TekWizely

LOL I know right!

for the record, the project idea came first, and the brainstorming for names came after.

But it was definitely a eureka moment that made me double-excited to create and share the project !

Thanks [for] the comment,

-TW

Greetings! Thanks a lot for taking the time to look at Bingo.

1: re: copy-paste install script: I'll definitely grind on this and see what we can do. Bingo requires my Run[1] package, which itself is written in go and can be installed via `go install github.com/TekWizely/run` -- Additionally, once you have Bingo installed, you can use IT to re-install Run and then manage your Run installation via Bingo itself ! A self-running install script for Bingo that installs a temporary version of Run, then installs Bingo, then uses Bingo to install a permanent version of Run would actually be quite clever !

2: re: metapackages: Bingo's goal is to be a useful wrapper on top of Go's built-in, and highly useful, install feature. Go's auto compile+install features are already getting pretty complex (ie code generation, specifying tags, etc)... The fact that you can download and install hugo with `--tags extended` from the command line is pretty sweet. That said, I would say any additional support (ie metapackages) might first start as a request against go install proper -- That said, it might be a nice addition to maybe fetch some kind of `go.install` file that contains basic steps for installing a complex package. If it was going to be a non-sanctioned idea, I would still want the format of the file/spec to stand on its own and be useful outside of Bingo.

3: re: shell/path setup script: PRs always appreciated ;)

4: Graci ! I am quite pleased with myself for the name - BTW: The idea for the tool came first. I then brainstormed the name ...

Thanks again and please lemme know if you have any further comments/questions! If nothing else please consider opening Issues for these ideas to help me keep track of them :)

-TW

[1]https://github.com/TekWizely/run

Hi!

Bingo is basically a wrapper over `go install` that makes it easier to manage the binary after installation. ABI and Distro etc issues are resolved however Go resolves them internally.

The beauty of Bingo is that it uses Go's built-in project install feature, ie. its as easy as as replacing `go` with `bingo` :

   $ bingo install package-url

you don't need to maintain any package information.

I'm not sure if nix can install (+ manage) golang binaries from the command line using _just_ the package url / binary name?

LOL Actually one my hopeful future additions is to maintain (or use discovery) a list of name-to-repo mappings.

ie. I would love for users to be able to just do:

   $ bingo install hugo
   ... installing github.com/gohugoio/hugo

I don't really want the concept of any project _owning_ a name, so in the cases where multiple projects were mapped/discovered for a given name, we'd want to ask the user which one they wanted to install.

(I was on xmas vacay so missed the initial post)

Wow what a nice random surprise - Thanks OP for the call out!

Go already makes installing go apps extremely easy, ie:

    go install package-url

What Bingo tries to do is make _managing_ that installed binary just as easy.

Once installed, you can then manage the installation by the binary's name.

An example I personally use:

    $ bingo install github.com/gohugoio/hugo
    # ... two versions later
    $ bingo update hugo

I'm happy to try to answer any questions - else I'll be perusing the comments looking for places to chime in.

Thanks again,

-TW

Just a quick drive-by to say thanks for the call-out - I hope you're finding run to be a useful tool and would love to hear more about how you're using it!

Clickable link: https://github.com/TekWizely/pre-commit-golang/releases/tag/...

I see this post has finally devolved into a discussion around using make as a task runner (it hadn't yet when I first read the article yesterday)

With that in mind, I toss my tool into the ring:

Run: Easily manage and invoke small scripts and wrappers - https://github.com/TekWizely/run

> If you want a glorified shell script which runs commands

Give my Run tool a try:

Run: Easily manage and invoke small scripts and wrappers https://github.com/TekWizely/run

Hey thanks for the bump !

I sometimes chime in on posts where OP makes a tool in the same domain as Run.

When I hit this article yesterday, the bash script convo hadn't started yet and I saw the OPs creation as not being in the same realm as Run, so didn't chime in.

But now that its been mentioned :)

Anyway I got a few extra subs from your call out, so thanks again for that!

(actually I just spent the last 30 mins reviewing 24 hours of HN posts to see where the call out might have come from, and finally found it :) -- Surprisingly google hasn't indexed this post yet so didn't show up in my saved search )

Do you find yourself using tools like make to manage non build-related scripts?

Build tools are great, but they are not optimized for general script management.

Run aims to be better at managing small scripts and wrappers, while incorporating a familiar make-like syntax.

I am happy to answer any questions you might have.

Thank you,

-TekWizely

Author here,

The linked dev.to post goes over recent features and bug fixes for the latest version of Run: v0.7.0

If you've been following run, I hope you'll find these updates useful.

If this your first time reading about run, and if you're at all interested in managing task runners and scripts, I hope you will give my project a try.

I am happy to answer any questions you might have.

Thank you,

-TekWizely

I see a couple of posts mentioning IndieHackers.

I'd say IH is a great resource for "Side Hustles"

But I think of "Side Projects" as a different thing.

It doesn't look like the place where you post your OSS GitHub project hoping to find (non-paying) adopters and build a community.

The channels I'm trying to use, in order of most success:

* Hacker News

* Dev.to

* Reddit

* Twitter

Hi @mmgutz,

Thanks for linking these other projects - I'm going to add a section in my README linking to other projects that people might find useful for their various use cases.

Go-task feels like a build tool and not really a general task runner.

Looks like Just brings a lot of similar features and I will definitely be looking into it deeper. However it still touts itself a build-tool at heart.

Run is NOT trying to be a build tool - It wants to be a script/wrapper manager and so the feature set is trying to optimize for that.

Thanks for the question - I hope that helps - Please let me know if you have any other questions or comments.

BTW: Can you link to your "own personal task runner" ? I'd love to see it and others might find it useful, too.

Hi @kariert,

I think a first answer could be answering with a question:

"Why do so many people use makefiles to just manage tasks/scripts/wrappers instead of using pure bash scripts"

One reason may be that they are already using make in their project for actual build targets, but I see many pure task-only makefiles out there, so its not the only reason.

I think another reason is ease of use - The syntax is very terse and you can get a useful task runner with just a few lines of text.

With regards to Run, one of the additional features it brings is the ability for your 'commands' to be any type of script and not just bash.

You could have small scripts coded ruby, python, perl, etc all mixed together and managed within a single Runfile.

Thanks for the question - I hope that helps - Please let me know if you have any further comments or questions.

Hi @brian_cloutier,

A couple of things that come to mind (although I should probably flesh out a section on the README for this):

* Auto-Generated Help From comments - There are patterns for adding a 'help' target in make that generates light documentation for the targets - I maintain a gist for such a pattern in a different github account.

* Per-Command Shell - bash, python, ruby, you decide !

* Per-Command Options/flags - With documentation!

* Positional Arguments - By default, make treats all non-variable arguments as targets, so you can't say "make action argument"

* Commands Executed in One Sub-Shell - By default make executes each line of a recipe in a separate sub-shell, requiring you to use '\' to link multiple lines into a single recipe.

No doubt make is useful for this, hence why all my dev friends use it, but make was not designed to manage non-build-related targets, and has some cracks in it with regards to that use case.

I think (hope) run can prove useful as a dedicated tool for this use case.

Thanks for the question - I hope that helps - Please let me know if you have any other comments or questions.

Thanks @a_band - Please don't hesitate to submit a bug report (or feature request!) if you get a chance to play around with it.

I must admit robo is clever for using YAML where I built an entire parser to do somewhat the same thing :)

Greetings!

Yeah I haven't done much with Package managers (PKGBUILD, brew, etc) and thinking this project might be my excuse to start learning them.

Thanks for your kind words and offer for a PR - I'll keep an eye out for it !

Greetings!

I would say that expect is quite a different beast entirely. I think of expect more as an interactive scripting language. Something you might use in place of bash to write a small script that requires user interaction.

Run is more of the tool you might use to organize your expect / bash / etc. scripts and easily invoke them.

Pretty much every dev I know has used makefiles as a means to organize small, non-build-related, scripts and shell wrappers. Run hopes to be a better tool for doing that.

Thanks for the question - I hope that helped - Please let me know if you have any other questions or comments.