Re: Writing .el files for org in org?

[Rainer M Krug <Rainer@krugs.de>]

[-- Attachment #1: Type: text/plain, Size: 4065 bytes --]

Grant Rettke <gcr@wisdomandwonder.com> writes:

> 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.

I started with org the other way around - as a tool for literate
programming and slowly getting into org as tool for organizing.

>
> 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.

How involved this becomes, depends on how much you customize your
tangling. If tangling is done on a highly customized emacs / org
installation, it will be difficult to reproduce. But if tangling is done
using a similar approach to what is done when using emacs.org, I don't
think it would be to difficult to do.

>
> 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.

If I understand you correctly, you are using Vagrant to develop your code
and to generate the release - that is a good idea. But isn't this an
overkill in the case of the context here? org (and emacs) should be
stable enough to tangle the same .el file from an .org file
(irrespective of whitespace and comments which do not influence the
functional aspects).

Cheers,

Rainer

>
> Safe travels.

-- 
Rainer M. Krug, PhD (Conservation Ecology, SUN), MSc (Conservation Biology, UCT), Dipl. Phys. (Germany)

Centre of Excellence for Invasion Biology
Stellenbosch University
South Africa

Tel :       +33 - (0)9 53 10 27 44
Cell:       +33 - (0)6 85 62 59 98
Fax :       +33 - (0)9 58 10 27 44

Fax (D):    +49 - (0)3 21 21 25 22 44

email:      Rainer@krugs.de

Skype:      RMkrug

PGP: 0x0F52F982

[-- Attachment #2: Type: application/pgp-signature, Size: 494 bytes --]