Skip to content

support standard project structure for OTP application #99

Closed
yzh44yzh opened this Issue Oct 16, 2012 · 13 comments

7 participants

@yzh44yzh
  • deps
  • apps
    • my_app
      • ebin
      • include
      • priv
      • src
    • my_other_app
      • ebin
      • include
      • priv
      • src
      • test
@yzh44yzh yzh44yzh was assigned Oct 16, 2012
@vladimirk

I believe this is not standard project structure. OTP design principles document defines application structure: http://www.erlang.org/doc/design_principles/applications.html#app_dir but it says nothing about top level directories. As for me I use different module for different otp apps.

@yzh44yzh

Well, this documentation describes single application. But project can contains several of them.

This structure is taken from book "Erlang and OTP in Action" Martin Logan, Eric Merritt, and Richard Carlsson. This is respected book from well known authors and I think It can be considered as standard.

@vladimirk

Yes but it's important thing for idea not to impose nonstandard practices. There should be possible to config this way if one wants but not to impose. Most Erlang projects I've seen either have single app at root folder (single OTP app) or multiple apps in root folder. Another point is that ideas own typical project have structure of:

  • root_module
    • submodule1
    • submodule2
    • submodule3

It has builtin capabilities of configuring dependencies between modules those affect compilation process. This in future could help automatically support dependency tracking for *.app files, so as for me having single OTP app to be bound as idea module is a better thing than having whole new deps model handcrafted.

@ericbmerritt

@vladimirk you are confusing the OTP build artifacts (applications and releases) with Erlang source artifacts. Its actually quite common to develop multiple related OTP Applications in the same directory. Both Rebar and Sinan support this structure. The reason you often see only one OTP Application in a single repo is two fold . The first reason is because that is what Rebar (the most common erlang build system) encourages. The second is that you don't see many OTP systems (that is releases) on github. These tend to be behind the firewalls of companies.

So concepts to keep in mind. OTP Artifacts consist applications and Releases. Releases are made up of multiple OTP Applications. Releases are the things you actually end up deploying when you are building a production Erlang system. Many times releases are composed of OTP Applications that only have meaning in regards to each other and so are developed together (in the same directory in the structure that @yzh44yzh proposes).

Now wether you support it or not is up to you, if you choose not to support it just be explicit about it. However, you can't actually call them nonstandard practices for two reasons. The first is that OTP doesn't say very much at all about how the source is organized and the second is that projects with multiple applications actually mirror OTP Releases quite nicely in the same way that projects with a single app mirrors OTP Applications and again, the are pretty common in larger systems.

@vladimirk

@ericbmerritt I have nothing against multiple otp apps inside directory structure - I'm doing that way myself. My comment was only about whether proposed directory structure is standard or not. In particular my comment was about toplevel deps and apps structure. It's in the Logans book but I've never seen it anywhere else (I'm using ~25 erlang third party projects withing erlang projects in my company). So my comment was about making Logan structure "standard". And I'm completely agree that there is nothing in OTP that says about source code organization, that was exactly my point and we should be as flexible as possible and should not impose Logans structure as "standard".

@ericbmerritt

Ah, I read the original issue a bit differently. More as 'you should support this structure' not 'you should impose it as a standard'. You are absolutely right in that you shouldn't impose either organization. Martin and I recommend the above approach in the book for large projects, we like it and agree with it. But its not something that should be set as the only way to go.

@vladimirk

Agree then. My position in topics like this that we should allow people to go with their own preferences whether it's emacs code style or not, any source code organization, any build tool, any testkit, etc. No limitations just possibilities.

@vladimirk

Great book BTW, thanks:)

@ericbmerritt
@rambocoder

+1 for the second edition. Can you add material about gen_fsm and live upgrades?

@PureIso
PureIso commented May 3, 2013

Hi all,
I am new to these whole github thing. Anyway my question is basically if it's possible to implement the directory structure specified at : http://www.erlang.org/doc/design_principles/applications.html#app_dir as the second poster has illustrated?

Thanks in advance

@vladimirk

It is so. Specified directory structure is for OTP application not for the erlang project.

@xenolinguist

This is already working for me with a multi-app rebar project using the current plugin version. Should this issue be closed?

@ignatov ignatov closed this Nov 21, 2013
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Something went wrong with that request. Please try again.