Re: Writing .el files for org in org?

[Grant Rettke <gcr@wisdomandwonder.com>]

On Wed, May 21, 2014 at 3:21 PM, Rainer M Krug <Rainer@krugs.de> wrote:
> I am sure this would be possible, but would this be feasible? A good
> idea? Or would it be better to have an additional directory
> (e.g. lisp.org) which contains the corresponding .org files?

Great question. Anybody tangling with org-mode has either already
asked themselves this question, or will be soon. When I started out
with org-mode I looked at it as a writing tool, and that was true
until I started using the literate programming feature. Without the
right perspective, I got myself into a lot of trouble. When I started
looking at it as programming, and system management, things started
working out for me again. When you frame your question more as a
systems management question, it gets a little clearer.

What does it take to release your code to production? The simplest
form would be to keep your generated files in Git, tag the release,
and then you are done. That is the official and final version of that
release of the system. Following this approach means that you can
release it easily on MELPA and org and anywhere else that you need
because you know what you generated, how you generated it, and how you
tested it. Simple. The alternative is to release only the source
org-file.

This process is a little more involved. In order to sign off on
allowing people to use the system that is built with that org file,
you need to make sure that they are able to regenerate it using
exactly the environment that you intend. For example, you will tangle
with a particular version of Emacs, on a particular platform, with a
particular set of plugins loaded into Emacs when you do the tangling.
Perhaps you even want to specify down to the operating system, and
more. Whether you intended it or not, the entirety of the system that
you use to do the tangling, is the implicit specification for what
people should use to tangle it themselves. Sure, I am going a bit
overboard here, but generally people don't care about such stuff until
it breaks.

My personal preference is to go with the latter. It forces me to know
what is going on. Doing it by hand is so tedious and often error prone
though, so I'm investing in mastering Vagrant. Vagrant will let you
have a reproducible system so you can specify what you used to build
your release (generate), and let others do that too if they want. The
only difficult is how lock that down for deployed code. Surely most of
the time you may just do the generation on deploy, eg via ELPA or its
kin. It just depends standard you want to, and must, hold yourself
too.

Safe travels.