emacs-orgmode@gnu.org archives
 help / color / mirror / code / Atom feed
From: Grant Rettke <gcr@wisdomandwonder.com>
To: Rainer M Krug <Rainer@krugs.de>
Cc: "emacs-orgmode@gnu.org" <emacs-orgmode@gnu.org>
Subject: Re: Writing .el files for org in org?
Date: Wed, 21 May 2014 19:30:25 -0500	[thread overview]
Message-ID: <CAAjq1mdw1JmWD=BBvd_6Y+fZjUhrybUyHmHJ2RUtvLhQTBtX1A@mail.gmail.com> (raw)
In-Reply-To: <m2oayq51dz.fsf@krugs.de>

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.

  parent reply	other threads:[~2014-05-22  0:30 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-05-21 20:21 Writing .el files for org in org? Rainer M Krug
2014-05-21 23:25 ` Aaron Ecay
2014-05-22  8:12   ` Rainer M Krug
2014-05-22  8:56   ` Bastien
2014-05-22  9:25     ` Rainer M Krug
2014-05-22  9:29       ` Bastien
2014-05-22  9:54         ` Rainer M Krug
2014-05-22 11:04           ` Bastien
2014-05-22 11:42             ` Rainer M Krug
2014-05-22 15:10               ` Bastien
2014-05-23  7:29                 ` Rainer M Krug
2014-06-02 11:22             ` John Kitchin
2014-06-02 14:00               ` Rainer M Krug
2014-07-27 21:50                 ` Bastien
2014-07-30  2:04                   ` John Kitchin
2014-05-22 15:44           ` Josh Berry
2014-05-22 18:49             ` Rainer M Krug
2014-05-22  0:30 ` Grant Rettke [this message]
2014-05-22  8:30   ` Rainer M Krug
2014-05-22 23:34     ` Grant Rettke
2014-05-27  8:45 ` Thorsten Jolitz
2014-05-27  9:07   ` Rainer M Krug

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.orgmode.org/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CAAjq1mdw1JmWD=BBvd_6Y+fZjUhrybUyHmHJ2RUtvLhQTBtX1A@mail.gmail.com' \
    --to=gcr@wisdomandwonder.com \
    --cc=Rainer@krugs.de \
    --cc=emacs-orgmode@gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).