Closed decipher3114 closed 4 hours ago
You can already list patches via the list-patches subcommand. Anything beyond that is matter outside of the domain of ReVanced CLI
@oSumAtrIX Getting a well-structured json file would benefit the third-party tools and it totally makes sense to add this to utility subcommand.
As I said, third-party tools have to work with the domain of ReVanced CLI and not the other way around. The list-patches subcommand is for reading the patches from the supplied patch files. Feel free to parse the output to a JSON as part of your domain requirements.
As I said, third-party tools have to work with the domain of ReVanced CLI and not the other way around. The list-patches subcommand is for reading the patches from the supplied patch files. Feel free to parse the output to a JSON as part of your domain requirements.
I hardly oppose this approach, the end result is that this just slows downs and adds complications for workflows where this wasn't the case before. It's a bit rough of a dismissal, I would really hope for a reconsideration on this.
ReVanced CLI is not a means to use in a workflow. This is your domain you are trying to fit in ReVanced's which you will have to solve on your own basis.
@oSumAtrIX Any CLI tool is meant to be used in a workflow, popularly known as "Shell Scripts". It is totally understandable if you feel lazy to implement it, but the reason is definitely not valid.
This is not a matter of laziness. At most its one on your end to parse the output to JSON as part of your domain requirements. You can use it in a workflow, but you will have to work with the domain of ReVanced CLI. I have been clear multiple times now.
Feature description
Add option to generate
patches.json
file locallyMotivation
This option will benefit third-party patching scripts after the removal of
patches.json
from releases.Acknowledgements