Mackup zap stanza import

[rolandwalker]

Add zap stanzas to 88 Casks based on data from the wonderful mackup.

I couldn't come up a clever way to leverage the mackup repo, given our current Homebrew-based infrastructure, so am importing some of the relevant data into the Cask DSL, now that we support zap.

Note that the brew cask zap verb is merged now but not yet in release.

cc @lra

[lra]

That's cool =)

I modified mackup's config file format to INI especially to let others being able to reuse and re-import those at will.
See https://github.com/lra/mackup/tree/master/mackup/applications
Isn't there a way you could reuse them directly? Or have an importer to regularly update your repo based on those?

Those files are frequently updated by the community and forking them might not be the best way to leverage this.

Not blocking this PR in any way ;) Just giving you the thoughts behind those CFG files.

[rolandwalker]

Yes, you are right that forking is a poor approach, and I would rather not do it - we should be finding ways to amplify each other's projects. Forking will dilute the energy.

One hangup I alluded to above is that we don't control our own distribution, as that is handled by Homebrew. It appears that a git submodule of mackup within our repo wouldn't propagate. Not sure what the answer is there; requiring an HTTP GET to do each zap seems fragile. We could check in a literal copy, but that's also a fork.

We also don't include an INI parser, though we will shortly. Though mackup's files are so straightforward it is not really needed. We would need a correct mapping from mackup name to Cask name.

I am not giving up on interop, though; there has to be a smarter way We are also taking a step in the outward direction by publishing static JSON copies of our dynamic Cask files.

[lra]

I don't mind updating mackup application names to match homebrew's as they usually make sense and we are not far, but not sure how to keep things in sync later.

Regarding the forking, would it make sense if I create a mackup-applications git repo with only the cfg? Like you mentioned, I could use a git submodule on my side, nothing prevents this, and in the future, you could reuse this too.

In this repo, there could be tools to transform the apps database into whatever makes sense. Example, a bin/export-to-homebrew-cask that would read the CFG files and update the cask files. You would maintain this file and launch it from time to time to update your files (then commit push the changes). Still a manual process, but 1 step closer to automation.

Just throwing ideas around.

[vitorgalvao]

I still don’t think this is the way to go about it. As has been said repeatedly, mackup does not sync everything, thus sourcing data from there will lead to incomplete results.

Not only is it incredibly hard to accurately get all the files relating to an application, relying on mackup will leave a gap. It is an acceptable starting point, yes, but nothing more.

[rolandwalker]

@vitorgalvao, I take your point that there is some impedance mismatch between the two projects. But they are coded by like-minded people, and there is definite overlap in the contributor communities.

For me, this about using the tech to connect the people. Collaborating is fun, if we can work out a sensible method.

@lra I will continue to think on your suggestions. We also have yet to see whether there is uptake by our Cask authors on the zap stanza. It is always possible that the community follows other interests.

[vitorgalvao]

For me, this about using the tech to connect the people.

A worthy goal, certainly. However,

Collaborating is fun, if we can work out a sensible method.

Agreed, but this is an inferior method. Users don’t care about who we’re collaborating with, or why (nor should they), they care about something working as expected (as they should). Having a substandard feature can be worse than not having it at all. Knowingly pursuing a deficient solution is something we shouldn’t really do.

[vitorgalvao]

In cases like this, for example, shouldn’t we just specify ~/.atom once, and be done with it? This way, we’re specifying a bunch of individual files (subject to change), and leaving the directory.

[rolandwalker]

Good point.

I have scripted this quite roughly from the mackup source and not reviewed/adapted.

[tapeinosyne]

This is an instance of a general problem: ~/.atom may contain user-created files, the deletion of which could be unexpected or undesirable.

[vitorgalvao]

Agreed. Although if you’re consciously zapping everything, you should probably be aware of that. How are we getting rid of them? If we trash files instead of deleting them, the problem may be mitigated.

[rolandwalker]

:trash exists in the DSL now, but only works as a :files synonym.

The general problem is another good point. As policy, we should document that zap should not delete user-created content. On the technical side, we can add a :rmdir key that means rmdir-if-empty. That way, ~/.atom can still get cleaned up if no user content exists.

[rolandwalker]

Merging, after doing some hand-cleanups per the discussion on diff above.

:rmdir support is also coming.