Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

The Asimov Roadmap #51

stevegrunwell opened this issue Dec 16, 2019 · 16 comments

The Asimov Roadmap #51

stevegrunwell opened this issue Dec 16, 2019 · 16 comments


Copy link

stevegrunwell commented Dec 16, 2019

Asimov hasn't been getting the love it deserves, and I'm happy to welcome @sudar as a co-maintainer (see #48) to help things along.

I have a lot of ideas for where I'd like to see Asimov go, but want to open them up to the community for thoughts + discussion before implementing.


Get Asimov submitted to Homebrew (#2)

This has been a goal since the beginning of the project, but Homebrew's policies dictate that the repository needs to meet a certain threshold of stars (50) on GitHub in order to be considered. Fortunately, this was exceeded some time ago, so now it's a matter of getting the Homebrew recipe in-place. I had started (and then re-started) this effort, but #34 looks the most promising. I'm totally the blocker in reviewing and approving :/

Introduce automated testing (#31)

The logic as it stands right now is pretty straight-forward (match a config/dependencies file with its corresponding installation directory and, if found, exclude from Time Machine) but having something that could run in a CI environment would be extremely useful to make sure we're not breaking things as we go.


Introduce a configuration standard (#27)

A number of issues have hinted at the need for a user-level Asimov configuration file, enabling individual users to configure not only the patterns that should be matched but also other directories (#28), whitelist specific directories (#14), and more.

Issue #27 proposed something like an .asimovrc file, which could be used to store Asimov configurations.

Expand beyond development dependencies

Asimov was designed for developers, but there have been some great suggestions around other things that can be excluded from Time Machine (for example, Spotify caches, suggested in #39).

If Asimov becomes something of the de facto tool for keeping Time Machine backups limited in scope, there are a number of other file types that we might want to include:

  • Multimedia render files
  • Caches and log files
  • Thumbnail metadata

Possibly rewrite in something besides Bash?

Asimov is currently written in Bash, since it's essentially performing filesystem traversal, basic pattern matching, and then interfacing with the tmutil program; if we want to get into more sophisticated functionality (for example, asimov list to see everything excluded from Time Machine backups, it's probably best to consider rewriting in a different language.

My default direction would be as a Symfony Console application, but that's mostly because PHP is my primary language (and PHP comes pre-installed on MacOS). An abstraction around tmutil will make the tool easier to work with, and Symfony components are designed to be well-tested. Distributing it as a PHAR means we still only have one file being installed.

The drawback here is that MacOS typically ships with older versions of PHP, which means the package would either need to be written using older PHP conventions, PHP would need to be marked as a dependency within Homebrew, and/or support would need to be restricted to versions of MacOS that ship more recent (read: PHP 7.2+) releases.

Make Asimov the go-to tool for interfacing with tmutil

The default tmutil tool shipped with MacOS isn't super-well documented, and is much more a developer tool than something intended for typical users. While I don't believe a GUI is necessary (Time Machine already provides that), providing a user-friendly Time Machine interface would be helpful.

Potential commands could include:

add - add files/directories to the exclusion list
config - read/write entries from the user's .asimovrc file
ls/list - Show all files/directories that have been excluded from Time Machine
prune - Locate any directories/files that have been added to the exclusion list but no longer exist (which would address #38)
rm/remove - Remove files/directories from the exclusion list
scan - Scan the filesystem for any new files/directories to be excluded. This is the default behavior of Asimov today.

Copy link

muuvmuuv commented Dec 17, 2019

A rewrite would be great and I think PHP is good as long as we use PHP 7.4> (with typing support) but IMO a more low level language would make much more sense for this project. I would consider something like GO, Rust or Nim. All of them can be compiled to a single executable, shipping with brew is easier AND they come with great typing support and beautiful compiler errors. I don't know how familiar you or anyone else involved in this project is with those languages, but I had no difficulties learning Nim or Go (the basics) and I'm coming from JavaScript, PHP and Python.

Copy link

muuvmuuv commented Dec 17, 2019

Something else that come to my mind with prune. I would also – besides some location where the exclude-list/config is stored – add a place where Asimov caches the files/dirs it has added to TM.
So when prune is running it would remove files/dirs from TM that are no longer in the Asimov config (based on the cache) and files/dirs that no longer exists. TM would be somehow in sync with the config.

In addition to that I would do a prune together with scan to prevent issues and make it more user-friendly. Somehow it is kind of the same, right?

I would also add my opinion to the config file again; After reading the above I think it would make sense to put the Asimov config in ~/.config/asimov (unix standard) and place everything there:

  • config.toml: The config file (toml, json, xml or whatever makes the most sense with the rewrite base + I would add scheme support to prevent typing issues by users)
  • excluded.txt: List of extra directories to exclude (line by line to make it easier to maintain, with glob support)
  • cached.txt: Cached list of excluded files and directories including those package manager dirs

Copy link

sudar commented Dec 18, 2019


Thanks for including me as the co-maintainer 🎉

Also I agree with the list of priority that you have mentioned. Let me know if you want me to get started with any of them, especially adding the homebrew support.

Copy link

tomtastic commented Jan 20, 2020

Excellent roadmap, but is PHP a wise choice of language given the old version on MacOS - isn't this what Apple do to built-in software (fail to keep updated) shortly before they deprecate it entirely?

Would Python or perhaps better Go be options that @stevegrunwell and @sudar would be comfortable with?

Copy link
Owner Author

stevegrunwell commented Jan 20, 2020

I would agree re: PHP maybe not being the best choice. PHP's definitely something @sudar and I are both comfortable with (we first met working as engineers at a PHP-focused company), but doing any sort of rewrite in a language that we can safely assume will continue to be pre-installed on MacOS will be ideal.

Of course, if we're targeting a Homebrew installation, it's easy enough to say "if we don't have a current version of PHP, install it as a dependency", so not shipping a current version by default on MacOS may not be a dealbreaker.

I'm also kind of interested in playing with Go, personally, but Python might be a good middle-ground. It should also be pretty straight-forward to pick up, if xkcd has anything to say about it:

xdcd comic #353, "Python"

@sudar, do you have a preference? I feel like PHP will be the fastest/easiest to implement and really focus on building out these features without worrying about the language barrier, but I'm open to learning a new language if it makes sense to do so. We could also rewrite in PHP now, get everything hammered out, then replatform a second time down the road if there are big performance wins to be had?

Copy link

codexp commented Jan 20, 2020

I vote for PHP +1

And I think it doesn't have to be cutting edge PHP.
Even 5.4+ would be sufficient to do most of the things that Asimov can do today.

Much more important would be to know the distribution of any language that might come as an option.
And whether it is backwards compatible.

PHP is backwards compatible, so you just have to decide how far back you'd want to support older systems.

Copy link

sudar commented Jan 21, 2020


Being someone who have been caught in the let's rewrite everything before we release loop so many times in my life, especially with pet projects I feel we should do things in the following order.

  • Release the current version (even with just the features that we have currently) using homebrew
  • Fix any issues that might pop up because of homebrew and get it stable
  • Create a wrapper in PHP (you guessed my preference correctly) for tmutil, may be as a seperate package that can be installed via composer
  • Once the PHP tmutil wrapper is stable, rewrite Asimov to use the PHP wrapper
  • Release v2.0 of asimov which uses this PHP wrapper
  • Rewrite if needed (because of performance issues or flexibility issues or to learn a new language) eventually.

Copy link
Owner Author

stevegrunwell commented Feb 4, 2020

I'm on board with this; let's get the current version into Homebrew before looking at rewrites.

Copy link

solipsist commented May 7, 2020

I love this little utility. It keeps TM backups running fast and smooth.

As for feature priorities, I believe that addressing hourly backups is a good idea as discussed here: #54

A common issue with tools like these is new changes in MacOS. I think the feature set is fine and all I wish is that it's maintained and kept up-to-date. I'd be happy with what there is if I can keep using Asimov for years to come with smooth upgrades as we switch 10.16, 10.17 and so on.

Regarding language and performance, Ruby or Perl would probably be good choices.

Many thanks for sharing your work!

Copy link

partyka1 commented Jul 13, 2020

Excluding paths based on assigned tags would be neat - one could exclude specific files/directories directly from Finder using context menu and get graphical overview what's been excluded

Copy link

t0r0X commented Jul 1, 2021

Python, Ruby, and Perl packaged with macOS have been deprecated, see section "Scripting Language Runtimes" in
Also PHP:

Not many options left: Zsh and Bash. Maybe Zsh is the way to go, or rely on dependencies from e.g. Homebrew.

Copy link
Owner Author

stevegrunwell commented Jul 2, 2021

Well, that's fun. Since Asimov is very much a developer tool I'm not overly opposed to defining dependencies for the Homebrew installations, but would definitely want to keep them loose (for example, if it's PHP, support several versions back; you don't have to install PHP 8 just to run Asimov, but as long as you have something in the 7.x branch you're okay).

Keeping it as a shell script is still an option, of course, but unless there's a ZshUnit that I'm unaware of the test suite will still need to be written in another language.

Copy link

t0r0X commented Jul 2, 2021

😁 Like e.g. these?

S.c.n.r. I'm fine and happy with any working decision, and am really glad I found Asimov, because it solved my issue and your work made me research deeper into these parts of macOS (I'm still a curios developer, after all these years).

Copy link

muuvmuuv commented Jul 3, 2021

What about using Swift because its macOS only ^^. I bet integrations to TimeMachine etc. would also be better.

Copy link

tg44 commented Oct 11, 2021

I started a repo; far from feature-ready, but I can do most of the things from code as asimov could right now, possibly faster with multithreading, and already handles configs with search and exclude paths.
If sb interested :)

(I'm totally noob at golang, this code was written in about 16h, and I had another 8ish ours in the lang, so any tips are also apprechiated!)

Copy link

chmac commented Mar 3, 2022

Would it be crazy to suggest keeping asimov as simple as possible?

I have written all kinds of open source software myself, and the maintenance is always hard work. Sometimes I have motivation and time, sometimes I don't. The simpler the tool, the less maintenance, at least that's my thinking. Although maybe @tg44's heptapod is the simpler alternative?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
None yet

No branches or pull requests

10 participants