Directory structure for a release

[Wiger Ulf]

(I had a longer answer to this almost ready, but Outlook Express
segfaulted and left nothing of it, so here's a short answer)

- Unless you run with the '-mode embedded' flag, erlang will not
  load modules unless they are actually called.
- How you want to organize your code is pretty much up to you
  and your administrative routines, but OTP's release handler
  likes to upgrade code on a per-application basis. This is 
  rather an argument for _more_ applications than fewer.
- I would try to create my applications so that each module in
  an application logically belongs there. Typically, I would try to
  have one interface module (possibly a few) for one application, 
  and keep only modules in there that are specific to implementing
  that interface.
- It is perhaps useful to have a 'utilities' grab-bag application for 
  those modules that don't seem to belong anywhere else, but I
  personally don't think it should be the norm.
- It's perfectly OK to have several code roots (several lib/ directories),
  if you feel that that's a more comfortable way to organize your code.
- To build different "systems", I'd create different "release" directories,
  under which I'd collect database, logs, application-specific files, and 
  OTP release handler scripts. All the code might well reside in one 
  place, under one lib (just be careful then with 
  release_handler:remove_release())

/Uffe

----- Original Message ----- 
From: "Jay Nelson" <jay@REDACTED>
To: <erlang-questions@REDACTED>
Sent: den 27 april 2003 01:10
Subject: Directory structure for a release


> I am trying to package up some code according to OTP
> principles so that I can do code upgrade / downgrade
> and have bootable nodes and a pool of clients.
> 
> I am probably getting confused between traditional code
> partitioning and the OTP way so I wanted a little guidance.
> I am trying to avoid having a lump of code that ends up
> causing things like in the OTP distribution where some
> useful utilities are part of the HTTP module and so on.
> Since I am just starting now is the time to get the directory
> partitioning right.
> 
> I have the following "code sets":
> 
> 1) Utilities (bin_utils, tcp_proxy)
> 2) HTTP utilities (web_utils, ProxyModule)
> 3) Host supervisor
> 
> I've got all the lib/App/ebin, src, priv and so on, but my
> question has to do with what is an app and what is a
> code organization structure.
> 
> I expect to use #1 Utilities for many projects.  I expect to
> use #2 HTTP Utilities only for this application.  Likewise
> the hostsupervisor is specific to this application.
> 
> Originally, I thought to put all three in separate directories
> and to have other directories for other shareable or non-
> shareable pieces, but it means each becomes an app with
>   *.app file and so on.  It also means (I believe) that they
> are regarded as part of an application tree whether or not
> they have processes running or are code-only.
> 
> Now I am wondering if one of the two following approaches
> is better:
> 
> 1) All in one directory
> 2) Host supervisor / HTTP utils in one; Utilities in other
> 
> Reasons for #1:
> a) They are all part of a single application
> b) Code upgrades can still occur on a module basis
> 
> Reasons for #2:
> a) The first directory is really the application
> b) Utilities is shareable to other applications
> 
> One of my concerns is whether code is compiled and/or
> loaded if it is not used.  In other words, if I use the first
> approach and dump everything in a single app directory
> and later write a new app that uses some utilities, will it
> require all the modules in the app directory or only the ones
> listed in the script file.
> 
> What advantages and disadvantages are there to having
> an app directory that contains only code and no processes
> as in #2?  Does it make configuration harder with no gain
> in code partitioning or loaded binaries?
> 
> If I write a 2nd application do I just dump it in the same
> directory and write a different release configuration, or
> should I go with approach #2 so that I create a new app
> directory?
> 
> Is it best to have as few directories as possible under lib,
> but at least one per bootable application?  Is there any
> advantage to partitioning the directories on a finer scale
> so that they are equivalent to libraries of related modules,
> or should there be one big utilities library (code-only app)
> containing all shareable code (a la stdlib)?
> 
> jay
>