Radare2: Remove "projects" feature until it's implemented properly.

[XVilka]

It doesn't work anyway, proper implementation will require some time, people try this feature and go away disappointed because it doesn't work in 98% of time. I think it's better to remove them completely until they are properly implemented.

• [ ] Remove the code
• [ ] Remove the commands
• [ ] Remove mentions from manpages and help
• [ ] Remove mentions from radare2book
• [ ] Go through radare2-extras and r2pm to remove all usages if any.
• [ ] Make a public announcement on blog, twitter, social networks about removal of the feature.

[unixfreaxjp]

I taught people who learn r2 in beginners level in my community to create project to save their stuff.
I understand the situation, as users, so I am not against this feature's deletion due to mentioned circumstance.

However, please make a proper announcement if the project feature is completely removed. So I can refer it to documentation that I made. Adding "announcement" in these tasks will be appreciated.

Remove the code
Remove the commands
Remove mentions from manpages and help
Remove mentions from radare2book
Go through radare2-extras and r2pm to remove all usages if any.

@XVilka
cc: @trufae

[thestr4ng3r]

fyi a rewrite of projects is currently in process: https://github.com/thestr4ng3r/r2db

[trufae]

I don't think removing it is the way to go to "fix" projects at all. Actually because a plugin can't add/remove flags in the program. Actually the logic of P/Ps should be generic and work.

As I stated in the past from my alter-ego @radare i don't use projects and that's the reason why i didn't spent much time on them to make them work properly. but i dont think it is that difficult to fix them, because i did all the logic needed in RBin to make that work.

Instead i would suggest to expose the project_save and project_load callbacks in the RCorePlugin struct and a prj. eval variable to select which implementation to use.

Another option would be to disable them completely until a tested implemented is there. Or at least show a warning for the user to make them aware that this "feature" is not expected to work, so users wont be complaining that much.

Personally I don't like the approach in r2db, but I understand the importance of projects and stability of those for the end users. And the difficulty of making them work in all the situations that r2 can handle is way more difficult than in any other tool out there. Despite this excuse, my proposal is the following:

• Add a warning to avoid the users trust/use this feature until its properly implemented
• Allow Core plugins to be able to save/load projects (this way it will be possible to load IDB files into r2 natively for example)
• Fix the projects in r2 with proper tests.

[thestr4ng3r]

The problem with the script-based approach is that by design it is strictly coupled to the semantics of commands, which have much more side-effects in place than what is needed for a plain save and restore. To make it work it would require huge amounts of tests, considering every corner case. In addition, because it is not a structured format, there is no way (or none without hacks or huge logic) to migrate between versions. So as soon as a command's behavior is even slightly changed, they will be broken.
That is why I see no reasonable future in the script-based projects at all, strengthened by the fact that not a single active r2 developer seems to be willing to maintain them.

However, what I do see as a very useful approach to a project-like thing is using companion scripts, which is usually done by hand. The current projects could be made into more of an automatic script generator. This way it is made explicit that what you get is a script and not a 1:1 dump of all state. But again, this of course depends on someone willing to change it that way and because projects in their current state have pretty much no usefulness I am for removing them completely.

[ulidtko]

This gets a strong bold -1 from me.

Main reason: despite being imperfect and buggy (like the whole radare2 itself), it's still very useful.

Secondary reason: I fail to see what the removal will achieve besides inflicting suffering. Ps/Po can be incrementally improved IMO.

[...] To make it work it would require huge amounts of tests, considering every corner case.

No; this is exactly the use-case for fuzz-testing. With not much code, it'll find all those corner cases for you. With not much code, it can find Ps idempotence violations, Ps; Po identity violations, version regressions and whatever other properties one cares to formulate.

I agree with "something needs to be done with r2 projects" — but as soon as the "something" takes the value of "remove for indeterminate time", I disagree strongly.

[ret2libc]

Did we reach any conclusion on this? I'm personally for removing the feature because it is as unreliable as possible, thus something I would not trust using in any case. However, if users think it's better to keep the feature as is until a replacement will be available, I'm ok as well.

Let's try to reach an agreement in less than one month, so we can either close this issue or work on removing the feature.