Implement rebar3 grisp clean

[eproxus]

A task rebar3 grisp clean should be implemented that works in the following way:

• Called as is, it should delete
  • _build/grisp
  • _grisp
  • ~/.cache/grisp/packages/*.temp
• Called with --full it should also delete:
  • ~/.cache/grisp
  • ~/.cache/rebar3/plugins/rebar3_grisp

It should ask for confirmation for either each individual folder/file or for some logical groups of folders and files.

[Laymer]

Hi :)

I don't know if that could be of any help for this enhancement, but since for our work with Lasp on GRiSP we've had to clean (_build,_grisp,caches,embedded elixir libs, ...) and rebuild many (many) times, I've written a Makefile as a quick hack for cleaning.

I've had the idea when I saw a similar one on the Lasp repository and in our case it does the trick. All the cleaning targets are declared as phony ones so it doesn't actually interfere with other automake/autoconf parts, and we are also able to use it to deploy or run a shell quickly when testing since we are mostly calling the same commands with same arguments over and over.

I am really not familiar enough with rebar providers so I haven't digged in that direction, but if I understand correctly it would yield the same result as a "rebar3 grisp clean". And I've been able to use targets for dependencies too, so stuff like rebar unlock/update/upgrade can be done calling make as well after cleaning for example.

Hope this helps :)

[eproxus]

@Laymer We'd love some help on this! We unfortunately can't (and don't want to) ship a Makefile with the Rebar 3 plug-in (or bake it into the generated applications), and it is much nicer if the functionality is baked into the plug-in.

If you want to help writing the Erlang task, a good introduction would be the Rebar 3 documentation. Secondly, you can look at our two task implementations for some inspiration:

• https://github.com/grisp/rebar3_grisp/blob/master/src/rebar3_grisp_build.erl
• https://github.com/grisp/rebar3_grisp/blob/master/src/rebar3_grisp_deploy.erl

[pablocostass]

Hey, would it be okay if I gave this a try? Also, how would you go about asking for confirmation before deleting each file/folder and is the confirmation even necessary? The user should known beforehand that calling rebar grisp clean [--full] is going to delete some files/folders.

I mean no offense, it's simply that rebar clean [--all] doesn't go out of its way to get the consent of the user before doing the clean (although I understand that even with the --all option it isn't deleting files from more "sensitive" places such as ~/.cache).

[eproxus]

@pablocostass You're more than welcome!

Ideally, we would have the majority of the code for this functionality in grisp_tools so that it can be used in the Mix plug-in as well. A first PR could be a nice Erlang interface for this feature is grisp_tools and then we can discuss how to integrate it with the Rebar plug-in.

I think there's a blend between being nice to the user asking for confirmation, and having to confirm every individual file. For example, if you delete the OTP build directory that the plug-in creates, that's a lot of files (the whole OTP source directory)! I think there should be a confirmation for each major location (OTP builds, OTP cached downloads etc.).

[pablocostass]

@eproxus Sure thing, I'll PR the functionality to grisp_tools and then PR the Rebar plug-in here. I'm a bit busy right now but I'll try to get it done soon.

P.S: Do you have any tips on how to go about asking for confirmation?

[eproxus]

@pablocostass The way I would do it is to implement the raw delete functionality in grisp_tools and deal with confirmation in the plug-ins. You could parameterize the confirmation functionality into a callback fun in grisp_tools using the event system we have in there already:

• https://github.com/grisp/grisp_tools/blob/master/src/grisp_tools_deploy.erl#L39
• https://github.com/grisp/grisp_tools/blob/master/src/grisp_tools_deploy.erl#L310
• https://github.com/grisp/rebar3_grisp/blob/master/src/rebar3_grisp_deploy.erl#L84
• https://github.com/grisp/rebar3_grisp/blob/master/src/rebar3_grisp_deploy.erl#L153

Using that system, once you get a, for example, pre_delete event, you could ask for confirmation in the plug-in and then by convention decide the result should be a boolean and use it in grisp_tools to decide wether to delete something or not.

I'd be more than happy to bounce ideas on this, so don't hesitate to hit me up once you start designing or developing this!

[eproxus]

If you want a more in-depth explanation of how the event handling works, let me know!

[Laymer]

@eproxus very very interested in knowing more in details about how the event handling works too 🙂 I would be happy to help for the PR if I can, my current hacky Makefile is growing larger (and uglier) and a clean command in Erlang is something I would use very often ^^