Managing application settings

[matthewmueller]

Basically merging cask with: https://github.com/lra/mackup. It'd be pretty easy to add a settings key to the formula that would have a list of all the settings and preference files.

Then when you want to run the backup, brew cask backup. To restore, brew cask restore.

[phinze]

We discussed this for awhile in #homebrew-cask, here's the log from around that time: https://gist.github.com/phinze/7cd361150816bd85304e

tl;dr - provided that we want Casks to be a canonical source of application metadata, seems like it could be a good idea worth considering

[passcod]

We probably need to get @lra in here. I'd also say that having Mackup-Cask interop would be a great feature, allowing for:

• Painless switch from Mackup to Cask
• Config backup/restore/sync between Mac and Linux

[lra]

Hello there.
Nice project that you have here =)

I've read the IRC log but have trouble figuring out what's the plan ? You want to reuse Mackup's data ?

Can you clear things up ? I guess it's still being thought out ;)

[matthewmueller]

@lra basically it'd be nice to consolidate the formulas so they are all in one place. A lot of the preferences and support in Mackup would be very useful in Cask for things like backups and clean installs.

The goal of Cask is make it easy to automate installing, upgrading, and removing osx applications and the preferences and application support is a key part of that.

[lra]

I see, but I don't understand what you want it to look like.
Anyway, the biggest problem to reuse Mackup's data is that your formulaes are rb and Mackup data is in Python.

If we don't want to fork an "app settings" database, we need to use the same data.

I always made sure that Mackup needed no other dependency than the pristine python, and that it was only 1 file to copy (you can wget and run it) but I guess at some point it won't scale. Also I don't think it makes sense for Mackup to rely on github (or any file hosted on it)

What about having a applications.cfg file in INI format that will describe what to sync for each application ? This is something that you can maybe reuse ? You could update it whenever you want, or maybe just translate to your ruby format.

The problem with your way of doing formulas is that the conf is described in ruby, which makes ruby a dependency to read it.

I might be offroad here... Just throwing ideas around to narrow down to your needs

[passcod]

@lra I was less thinking in terms of shared config (that can be kept in sync manually, if it comes to that), and more in terms of interop. The way Cask would backup/restore/handle configs should be the same or similar (we might want to make Dropbox optional for Cask, instead allowing to specify a different folder, that kind of thing) as Mackup does, so that:

• transitioning and/or interop is as painless as possible, and
• (maybe) one can use both at the same time.

Regarding having a shared 'app settings' DB, this may be possible, but so far Cask has tried to keep everything within its file format, à la Homebrew, so I don't see this being very probable. As I said before, though, the concern is a minor one, especially due to Cask having a broader aim than Mackup (some apps might not have config, or backup-able config at least, and some people will not want to use Mackup-like backup/restore capability).

Like you, though, just throwing ideas :)

[lra]

What about keeping it the unix way: no overlapping or roles, but one calling the other. The only thing to share would be the application name.

Mackup could be used as a lib and brew cask could call mackup backup with the application list, so that mackup only acts for the given apps. Mackup can also be called directly as a lib in python (import mackup; ...) if you don't want to rely on the shell.

The brew app naming convention is a good one, Mackup could switch to it if there is a good reason.

This way you would just have to update mackup from time to time as a dependancy.

Again, just throwing ideas around.

[matthewmueller]

Yah that could work. Personally, I like the idea of having a community-driven repository that acts as a database for Mac apps. How to install them, where all the settings are, the version number, etc.

Then people could consume that repository with whatever tool or language they see fit.

[lra]

I'm planning on splitting the mackup binary and the application DB for easier merges, maintenance, and export of data (for things like cask)

I'm thinking about something like mackup/applications/some-cool-app.json. some-cool-app following the homebrew convention.

Would it help going forward ?

[lra]

I have nothing against the reuse of the mackup bin too.

[lra]

Going forward: https://github.com/lra/mackup/tree/master/mackup/applications

[rolandwalker]

@lra, thanks for the update. I am following this, though it may be a while until I get to any implementation. There are several interesting possibilities though.

Per #1005, I think the easiest/first-pass integration goal on our end might to be the ability to say brew cask zap <appname> to clean out relevant user prefs for an app.

[lra]

No worries, I totally understand this, it took me months to get the application definitions out of Mackup ;)

[vitorgalvao]

@rolandwalker Syncing preferences would work correctly, but deleting them would not, since mackup does not sync everything (and with good reason).

This means that in some cases, even thought the files would be deleted, the directories would not; while in others, preference files would be deleted, but the biggest amount of data would not. This would then lead to an incomplete feature that would not perform as users expect. In addition, like @leoj3n pointed out (and I did, as well), there’s no way to achieve this functionality flawlessly.

Setting it to act on files that users specify may (certainly not always) improve its accuracy, but in many (most) cases it’ll still be lacking. In addition, relying on a data set that is constructed with a very different purpose will not be ideal — I’d argue it’s actually the worst possible solution of the ones mentioned. For these reasons, I’m strongly against the inclusion of such feature.

To be absolutely clear, I’m referring solely to the delete preferences feature, not the syncing preferences one.

[yangm97]

What if one is temporally uninstalling an app? Maybe the files should be kept until user does something about it, just like Mac Apps has been doing. Also, by following Apple-styled behavior, user would need a tool to remove unused data files, like AppCleaner.
Maybe there is a more elegant way to do this, like setting a flag to remove leftovers of a given app after uninstallation (and also keep a track of those leftovers so user can remove them anytime).

[Anahkiasen]

👍 For this

[rolandwalker]

Some work toward this (as yet, only uninstall-oriented) has started in #4869 .

[vitorgalvao]

Closing. The feature makes no sense for now, and it strays a lot from the “one thing well” philosophy. Lets work on other pressing matters first, and revisit at a later date.