There is no great answer I am aware of. However, I will sometimes generate a markdown version of the source so that at least non-emacs users have a slightly better chance of being able to view the source in a more format friendly manner than a 'raw' org file. However, pull requests and the like are more likely going to be diffs on the generated sources as most people will want to use their preferred editor and that will likely need the generated source file is in order to get their editor 'IDE' features etc.
This is one reason I tend not to use org's 'literate programming' model for anything other than documentation, simple examples, configuration files, sql and basic scripting. I find for more complex development, especially when it requires multiple files, namespaces/modules, long running repl sessions, extensive test suits etc, using org adds another layer of complexity which soon outstrips the benefits of having documentation and source in one file. Of course, this will also depend on the development language/platform. I tend to use languages which involve a fair bit of 'REPL' based development rather than a more traditional write, generate, compile, debug loop. On the other hand, when it comes to documentation, tutorials, configuration files and workflow automation, org is definitely my preferred tool. Tim Greg Minshall <minsh...@umich.edu> writes: > hi. i apologize if this has been asked before (especially if by me). > but, since i had a question recently about Org Src... buffers, this came > up. > > i'm wondering what people do who want to release a non-emacs'y package > (an R package, say, or ...), and who did their development "from within" > a .org file. > > i can "build" whatever files are needed to release the package. but, > it's nice to be able to let people look at the sources, maybe submit > 'pull requests', etc. > > if anyone has any techniques they've used, liked (or hated), i'd love to > hear. > > thank you very much, Greg -- Tim Cross