Re: best practices query: non-emacs packages based on tangled source

[Tim Cross <theophilusx@gmail.com>]

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 <minshall@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