Consider reimplementing abra in $x language (not Bash) #102

New Issue

decentral1se · 2021-07-05T13:17:08Z

decentral1se commented

2021-07-05 13:17:08 +00:00

It is generally acknowledged that large Bash scripts are hard to write, maintain and extend. However, the context is important: the current iteration of abra was written in our free time and without any idea that we'd get paid for it. It has come up a few times, about a re-write of this tool in some other language. So, here is a space for that.

It is generally acknowledged that large Bash scripts are hard to write, maintain and extend. However, the context is important: the current iteration of `abra` was written in our free time and without any idea that we'd get paid for it. It has come up a few times, about a re-write of this tool in some other language. So, here is a space for that.

decentral1se added the

question

label 2021-07-05 13:17:08 +00:00

decentral1se commented

2021-07-05 13:22:01 +00:00

My thoughts:

This would be something for Beta -> Stable stage I think. Why? Using Bash is currently super flexible for changes. It has warts but while we're still really exploring interfaces, it is handy imho. The abra command-line is still a big design question, so the less boilerplate to move through, the better, right now.
If we were considering a rewrite, whatever we were considering would have to retain this "single binary" setup we have now. So, we do not push the responsibility of installing dependencies to the end-user (like is typically done in the world of Python).
I know that projects like https://github.com/dokku are eventually rewriting parts of their tool in Golang after years of running in Bash and finally running into insurmountable Bash nightmares around CLI parsing and UI/UX experience. They are doing a kind of piecemeal replacement where they rewrite some sub-commands and drop them in seamlessly. That sounds like something we could also do.

My thoughts: - This would be something for Beta -> Stable stage I think. Why? Using Bash is currently super flexible for changes. It has warts but while we're still really exploring interfaces, it is handy imho. The `abra` command-line is still a big design question, so the less boilerplate to move through, the better, right now. - If we were considering a rewrite, whatever we were considering would have to retain this "single binary" setup we have now. So, we do not push the responsibility of installing dependencies to the end-user (like is typically done in the world of Python). - I know that projects like https://github.com/dokku are eventually rewriting parts of their tool in Golang after years of running in Bash and finally running into insurmountable Bash nightmares around CLI parsing and UI/UX experience. They are doing a kind of piecemeal replacement where they rewrite some sub-commands and drop them in seamlessly. That sounds like something we could also do.

decentral1se changed title from ~~Consider re-implementing abra in $x language (not Bash)~~ to Consider reimplementing abra in $x language (not Bash)

2021-07-05 13:24:16 +00:00

3wordchant commented

2021-07-09 21:20:20 +00:00

If we were considering a rewrite, whatever we were considering would have to retain this "single binary" setup we have now

More motivation to rewrite: I've been thinking about it more, and we currently don't have a "single-binary" setup. The shell completion scripts will only be available if you install the dev version, or clone it manually, and we're also vendoring yq, jq, and requiring a growing list of OS packages to be installed.

I agree we can probably get away without worrying about a major jq or yq version upgrade, and maybe rolling the shell completions into the main script, until after the Beta, but consider me Very Interested.

Python, Go, Rust, are there any other options people have in mind?

> If we were considering a rewrite, whatever we were considering would have to retain this "single binary" setup we have now More motivation to rewrite: I've been thinking about it more, and we currently _don't_ have a "single-binary" setup. The shell completion scripts will only be available if you install the dev version, or clone it manually, and we're also vendoring `yq`, `jq`, and requiring a growing list of OS packages to be installed. I agree we can probably get away without worrying about a major `jq` or `yq` version upgrade, and maybe rolling the shell completions into the main script, until after the Beta, but consider me Very Interested. Python, Go, Rust, are there any other options people have in mind?

decentral1se commented

2021-07-10 13:55:52 +00:00

Hmmmm good point yep 🤔

Looking at https://git.autonomic.zone/coop-cloud/pyabra, it wasn't actually that bad a proof-of-concept and it could actually deploy things already. As for the single binary, I might give another shot and building it with https://github.com/Nuitka/Nuitka to see if it can indeed generate a x-platform binary.

If not, probably Golang is a safe bet here (I do not say this lightly) because the the Docker APIs are really suited for that and you can even drive Docker via non-public internals if needed? Also, single binaries are the default?

But I still think Python is probably the best fit for us, as we know it already?

Hmmmm good point yep 🤔 Looking at https://git.autonomic.zone/coop-cloud/pyabra, it wasn't actually that bad a proof-of-concept and it could actually deploy things already. As for the single binary, I might give another shot and building it with https://github.com/Nuitka/Nuitka to see if it can indeed generate a x-platform binary. If not, probably Golang is a safe bet here (I do not say this lightly) because the the Docker APIs are really suited for that and you can even drive Docker via non-public internals if needed? Also, single binaries are the default? But I still think Python is probably the best fit for us, as we know it already?

❤️ 1

decentral1se commented

2021-07-11 12:23:37 +00:00

Nuitka/Pyoxidizer are still really experimental 🤔

https://github.com/dokku is all Bash and is migrating to Golang:

Where the last one is the reasons listing.

So, I'm tipping towards Golang at the moment...

Nuitka/Pyoxidizer are still really experimental 🤔 https://github.com/dokku is all Bash and is migrating to Golang: - https://github.com/dokku/dokku/issues/2806 - https://dokku.com/docs/appendices/0.9.0-migration-guide/ - https://github.com/dokku/dokku/discussions/4258#discussioncomment-289670 Where the last one is the reasons listing. So, I'm tipping towards Golang at the moment...

decentral1se commented

2021-07-11 12:26:01 +00:00

The CLI package that Gitea are using (the main Golang reference I have) looks very usable:

https://github.com/urfave/cli/blob/master/docs/v2/manual.md#getting-started

The CLI package that Gitea are using (the main Golang reference I have) looks very usable: > https://github.com/urfave/cli/blob/master/docs/v2/manual.md#getting-started

👀 1

decentral1se commented

2021-07-12 18:00:46 +00:00

In some ways, the CLI kinda feels "stable" and we haven't really changed it fundamentally in some time. We've been adding and tweaking but in terms of the design, it has been somewhat fixed.

The final open design questions on the CLI seem to be these tickets?

If we could squash those then we could freeze the CLI in Bash mode. Then we'd have a fixed target to catch up with. Any additions could then be postponed until we archive the Bash implementation.

I've changed my mind from the original "This would be something for Beta -> Stable stage" thoughts because reading https://github.com/dokku/dokku/discussions/4258#discussioncomment-289670 and #102 (comment) and with all the nigtmarish ensure_stack_deploy wrangling in coop-cloud/abra#165 I feel like it might just be a better investment to ditch the Bash sooner rather than later?

In some ways, the CLI kinda feels "stable" and we haven't really changed it fundamentally in some time. We've been adding and tweaking but in terms of the design, it has been somewhat fixed. The final open design questions on the CLI seem to be these tickets? - https://git.autonomic.zone/coop-cloud/abra/issues/92 - https://git.autonomic.zone/coop-cloud/abra/issues/189 - https://git.autonomic.zone/coop-cloud/abra/issues/137 If we could squash those then we could freeze the CLI in Bash mode. Then we'd have a fixed target to catch up with. Any additions could then be postponed until we archive the Bash implementation. I've changed my mind from the original "This would be something for Beta -> Stable stage" thoughts because reading https://github.com/dokku/dokku/discussions/4258#discussioncomment-289670 and https://git.autonomic.zone/coop-cloud/organising/issues/102#issuecomment-7250 and with all the nigtmarish `ensure_stack_deploy` wrangling in https://git.autonomic.zone/coop-cloud/abra/issues/165 I feel like it might just be a better investment to ditch the Bash sooner rather than later?

decentral1se commented

2021-07-12 18:02:55 +00:00