Automation for the Rest of Us - Initial Release

Atros Release v0.0.1

Reason to Create a New Automation Tool

This is the way I felt when I tried to automate my developer setup with today's available tools: Goddamn! I'm not an owner of a billion-dollar company, I just need to reproduce my working environment, so that tomorrow's presentation, in which I'll have to use someone else's Mac, won't suck in a way that I risk an upcoming paycheck. But the owner of that machine is a brogrammer, I later learned. He doesn't have Node installed in his system, because Deno FTW! Couldn't guess that one, huh?

Or another example: You just ordered a new machine, and it's a killer, a beast. In your dreams, you see you're hacking with it, typing with its juicy keys super fast, and feeling productive at last. Wait, what is that? You use Arch btw in that dream? Oh, you must try it out! But now, you have to make the switch from your anime wallpapered Ubuntu, and while waiting for the new machine, you search what is the package manager of Arch, and what is the best way to install a package, what is Yet Another Yogurt, why is it different from Pacman? Is it Turkish or Greek Yogurt, or do they both mean the same thing already? (Forgive the national joke of mine)

While it's best to know everything above before using Arch, except for the history of yogurt, I needed a better way to automate the repetitive process of setting up. I needed a way to create cross-platform tasks and also a cross-platform way to test them all so I could test everything proactively before I was on that platform. Only then could I be confident when I switched from one machine to another. This is an interesting necessity, because Bash is too simple to meet it, and tools like Ansible are too complicated at the same time. There must be a sweet spot between them.

Status of Already Existing Automation Tools

To mention the status of today's automation tools while we speak of them, I must say that they feel like they are designed to be complicated! And they are, indeed. The reason for this is simple: Lack of focus. Or let me put it in a better way: They're focused on something so big that they can never be focused again. These tools serve corporations' needs, which is fine of course. But when it comes to serving corporations, you must hunt high and low. Because:

You need to show yourself big, so companies will feel safe using you. After all, you're too big to fail to cover every stupid edge case.

You need to be big and complicated enough to provide consultancy services to them. Because these products are here to make green, aren't they? Again, this is fine of course. But at the same time, this is hell of a reason not to keep things simple: You create a feature that's not necessary, since people could add one more line to their YAML to achieve the same result. But the goal is to be big, it has a bigger chance to get accepted. Then the product becomes even more complicated, and consultancy becomes more needed, but this feature doesn't contain printing to console what it did. So you need to add one more feature just to do that, instead of echo 'Hey, I did this and that btw', call it feature_with_print. And it goes on and on.

As I said, I'm not an owner of a big corporation for God's sake. I'll never command an army of computers. For me, the problem is so simple that the solution must be too!

Features of Atros

So, that's why I created Atros (Automation for The Rest Of uS) I needed a tool simple enough to enjoy using it, and I'm thrilled to share it with you. Let me list the main functionalities of Atros. I've praised the tool enough after all, didn't I :)

But before the list, here is the most important disclaimer: This is the first release of Atros, the v0.0.1. So, while the tool is fully capable of doing its main purpose, automating your tasks, it doesn't contain all of the solutions to every pain point that it's been created to solve. So it's 100% your right to tell me that I'm stupid enough to pontificate on a medium that I haven't achieved enough success to prove a better way. While having the right to tell me that, the reason I share the project early on in this point is about what I think is the best way to maintain a project. You can't create a useful tool behind closed doors, that is valid for all kinds of projects, and for every field, not just for programming. You need people; real users, and maintainers, to help you pursue your vision and help you remember that original vision when you get lost in the project.

With that being said, here is the list. Features that are not available at the moment are marked as (WIP):

• 💻 Cross-platform tasks: A task is a command you want to run on a machine, and every one of them has an optional field called "system", which can be equal to "mac", "debian", "arch" or "fedora" at the moment, and I'm hungry for your suggestions on the upcoming system supports btw! If you leave this field empty, this task will work in every system when you execute "atros run". If you specify either of these systems, you guessed it right, the task only works for the specified system. This is the simple way I handle cross-platform support. In the upcoming releases; this field will be able to take an array of strings too, to be able to define tasks that work on multiple defined systems.
• 📝 Task types: Today, we have "shell" and "install" task types. Shell has no magic, at all. You just write a shell command to the task's "cmd" field, and it happens. Like "cd", "ls", "git clone..." etc. Anything you can write to a sh terminal is available here. On the other hand, install is a little different. If your task is an "install", you need to fill the "packages" field with an array of strings, and you can also fill the "parameters" field, also with an array of strings. This type of task runs different commands in the shell depending on your system. If it's a Mac, it searches brew, if Arch, pacman, etc. There are some things that I could use from your perspective. For example, what about yay in Arch, etc? And in the next releases, I'm planning to add a checker for MacOS, to search if you installed Brew at the time you run an install task. If you didn't, it'll ask you to install, or maybe it'll ask if you want Atros to install Brew for you. A nicety to have, IMO. A small note about the install task: My Linux PC is not with me currently, therefore I couldn't test this feature for Linux distributions, so if you find a bug please report it. You might notice that currently, this task is a little limited because it misses the biggest feature it needs: Platform-specific parameters. For example, you're in Arch and you want to install a package, but you don't want to use pacman, you need yay. If you add "yay" to parameters, it'll look at your system, and you're in Arch, it'll create your command using yay. For other systems, the "yay" parameter will not change anything. Another example would be in Ubuntu. If you use the "get" parameter, it'll use apt-get, otherwise just apt.
• ⚙️ Configuration files (.config/atros/steps/): You write configurations in Typescript to create JSON objects, and in the future, you'll also be able to create steps directly using .sh and .json files. But why use Typescript to generate JSON? Like, you know, instead of using directly JSON. Especially when the tool itself was written in 100% Rust. Duh, right? Well, because while the language itself has many flaws, the language server is just a tailor-made solution to define documented conditional types. For example; when you define a task's type, the documentation says that if you define it as "shell", then you'll need to define a cmd field too, if you define it as "install" instead, you have to give it "packages" then. After you define your task type, intellisense gets updated, and for example, if you defined it as "shell", you'll only see the "cmd" field. "packages" and "parameters" fields disappear. As many of us know, if not all of us, this is one of the most important aspects that make a tool shine: Editor-driven documentation. A small success story of this aspect would be the Rust language :) It's easy to access documentation made me stick with it! When starting the project, I concluded that this was the most important feature. I want simplicity, therefore it must be delivered well. I would hate if I had to search for documentation on the internet before defining every task.
• 💾 Caching: The caching module was a required block of this project. Because when you run tasks, sometimes you pass, and sometimes you fail. This is obvious. But what are you gonna do when you both fail and pass? This is the part where we need caching because we don't want to run a task twice usually. With the caching module, if you try to run a task more than once, it prints that you've successfully run this task before, do you want to run it again? Also, I'll implement the functionality for saving the state when you exit unexpectedly. Perhaps I should call it Fearless out of Electricity, inspired by Rust :)
• 🤝 Interoperability With Node, Bun, and Deno: Like it or not, every developer has either Node, Bun, or Deno installed in their system, and as we discussed above, Atros takes advantage of this. When we run tasks, it first looks at which executor to choose in this order: Bun, Node (specifically npx), and Deno. Bun is first because it's slightly faster than running npx ts-node ... and Deno is the last one it looks because while being as fast as Bun, it's not a drop-in replacement of Node.js, and I've spent a good amount of time to be able to run it with the same structure that Node and Bun uses. So, it's grounded for not being collaborative in other words :) After finding an executor, a small Typescript code runs to turn each step into JSON.
• 🔑 Storing Sensitive Keys Securely (WIP): One feature I need is the ability to securely store my sensitive keys. Currently, I'm tackling this issue, and let's discuss the way I'm implementing the module. We'll have a new command atros key ... with create, list, reveal, and remove subcommands. You create a key with atros key create --name private_key --value "some private stuff" or you can use --read-file "~/file_path" instead of using --value. Simple, isn't it? Running one of these commands will ask you for a password to encrypt your key. After you enter it twice, it creates an AES encrypted file inside your .config/atros/keys/ folder with the same name you provide as args. Other subcommands are obvious in what they do. But when it comes to making these keys useful, how will you use a key you created? Well, simple. In the "cmd" field of a "shell" task, you can use {{variable_name}} to refer to a key's value. For example, "touch ~/.ssh/id_rsa & echo "{{ssh_private}}" > ~/.ssh/id_rsa" Be simple, be direct. Nothing fancy. This is a really good example of the direction this tool chose. I'm thinking of looking at the surrounding symbols of key requests, like "{{ssh_private}}" uses "". So, the content of this key has to be changed a little to make this shell command valid, replace all " with " for example.
• 🧪 The Testing Module (WIP): This module is going to be the biggest one so far because it opens lots of doors for different use cases. For example; testing your tasks cross-platform, testing first to see if our system is capable of doing things (which can be used to make it easier to contribute open source software, but like I said, the main focus is on setting up systems easily) running only failed systems etc. So there's a lot to cover, and the main problematic issue is the cross-platform one. We'll use Docker to simulate tests, that's for sure. Since Macbooks have switched to ARM, this might create problems in the future for supporting Windows, which we'll discuss below. No problem occurs for Linux distributions, open source is the best! To simulate MacOS, I'll either use a popular MacOS image, or I'll create an image that tries to simulate the MacOS environment best. I'm sorry I haven't come to a clear decision yet on this topic, like I said, this is the first version.
• </> Run & Test Tasks Without Having Them Installed Via Git (WIP): While using this tool for myself to figure out if it's useful, I've figured that I'd love to be able to use it without installing a config folder, just with git to test out if I have a compatible system with the publisher of a config. So, I'll add it for sure. Testing and running tasks with only a git repo is a cool use case! I guess that's all I can say to convince someone to add a feature to his/her project :)
• 🪟 Windows Support (Unclear In Progress): I know that at some point it has to be added to a project that's made for exactly this project's purpose. Even the given examples lead to Windows support. You use Linux and you have a presentation tomorrow, and the presentation PC is probably in Windows because it's everywhere, unfortunately. So it's a must, not a nicety. With that being said, I haven't used Windows for a long, long time, and I know nothing about it: Its package managers, configuration options, environment variables, etc. Therefore, I'd very much like to use the community's support here!

Phew! It's been a long ride, sorry for that. To sum up, I'm excited to share the first release of Atros, and thank you all so much for being interested enough to even take a glance at it!