I have some concerns about this feature.
- Is there any user-friendly OSS program to define and run workflows like the one you're describing? My guts feeling is that this problem has already been solved and I'm worried about half-way reinventing the wheel on this one.
- I recognize I have no experience in the field, but since the user still needs to know how to install and configure any third party program (R, Pandoc, Python...), and actually write scripts (or, at least, know how to use them), it doesn't seem like we're saving them much of the hassle by making Briefcase run their scripts.
I also see problems with the implementation of this feature, mainly due to the huge variety of environments we should have to consider. Basically, there's a ton of things we need to consider just to invoke a third party program on the host. This is a non-comprehensive list of stuff we won't ever know about the host's environment beforehand:
- Host operating system
- All the regional settings
- JDK version and vendor
- Location of third-party programs binaries
- Environment variables required to run those third-party programs.
Any unexpected variation of these things could make it impossible for Briefcase to even start the scripts. On top of this, we need to consider error handling and user feedback, which can be another challenge in itself.
Honestly, I'm worried about biting more than we can chew, especially if we can find an OSS alternative that would solve the sequencing of Briefcase and script invocations (which I'd bet it already exists).
I would like to propose an alternative path, though.
We could build a Docker image with Briefcase and any other third party tools like Python, Pandoc, and R build into it and provide simple commands to run pre-established workflows like the ones @chrissyhroberts is describing.
This would not only support the main feature of running scripts after a Briefcase export. It would also save the users the need for installing and configuring any third-party tool in their machines. Since the Docker environment would be known, we could enforce any required rule about output folder locations, etc.
If required, this Docker image could be developed in a separate repo that the community could work on and collaborate to improve the pre-established workflows.