You can clone with
HTTPS or Subversion.
Key sub_description currently specified in the .app files isn't recognized by Erlang release tools (systools and reltool). This is a non-standard key that is unsupported by those tools, causing warnings every time the .app files is processed by those tools (which happens when creating releases or calling most of the functions available in either systools or reltool modules).
The list of keys supported by the release tools is available here: http://www.erlang.org/doc/design_principles/applications.html#id73724
Remove an unsupported key from the .app file
What do you recommend for building releases then if not reltool? It's the same for systools.
Relcool (https://github.com/erlware/relcool) is a promising project that I am currently beta-testing for them. Once it fits my need without any remaining issues I will recommend it as the way to build releases. It replaces reltool and uses systools internally for small things.
By the way I'm guessing you see the warnings because you use the UI or something? You don't see warnings with rebar.
I've had rebar shouting at me because of this.
Thanks for recommending relcool, but I would rather use standard OTP applications. It's not because I don't appreciate relcool, but because of the requirements of my clients who I am writing the project for. I may consider relcool when it becomes a part of OTP. I am not using Rebar to create releases because of the same reason, so I don't know if Rebar shows any warnings or not (but as @aerosol suggests, it does).
I don't think it's right to say something is OK because Rebar or relcool don't complain. Neither Rebar nor Relcool say what's the standard in Erlang. OTP does. If both, systools and reltool complain then it means something is not OK. Unless, of course, Ranch or Cowboy is a low-visibility side-project which can disregard standards because no one cares about it anyway, which I hope is not the case.
BTW, May I ask why do you need that particular entry in the .app file? If it is used somewhere in the application I am happy to update the code as well. How about moving that text into the env section of the .app file (e.g. making it one of the environment configuration option so the application can still use it)?
It's not used by the application, but by tools around it that I need. Do note that it's only warnings, there's absolutely no harm in having these values there. They just end up ignoring them with a warning. If you really do not want the warnings, I would suggest using sed to remove these values at compile time for now. I do not have time to think of another long-term practical solution at this point. I need both the normal and the extra info from the app file, so putting them together really makes the most sense.
As a side note, I do not think "being part of the Erlang release" makes something more legitimate. Release handling is governed essentially by boot scripts and SASL, the tool used to build a release having little impact. Similar can be said about using Cowboy instead of Inets.
Let me also reassure you that Cowboy and Ranch are not side projects. But between getting something done and avoiding harmless warnings, it'll always be the former that takes precedence.
Thanks for your comment. The problem is that reltool shows the warning every time it consults the .app file. So, for example calling reltool:get_rel/2 produces two warnings (one for ranch and one for cowboy). If the reltool.config contains two releases, it will create two warning for each release. My simple escript, which I call from a makefile, actually produces 6 warnings every time it is executed because it creates two releases and calls get_rel once to create a file with the release version.
I may use sed, or I may just ignore the warnings for the time being, or I can even fork the project and fix it in a new repository. But as much as you care about comments in the source code, or that dialyzer doesn't throw out any obvious errors, I think as much you should care that a serious Erlang application is first and foremost compatible with OTP release tools before being compatible with any 3rd party tools. This is why I proposed the fix. It's not urgent; as you said, the warning is harmless. But it would great to see this issue addressed at some point. I am happy to help if there is any way for me to do so.
At some point. I didn't know about the warnings when it was initially done, and since the last time someone reported it I guess I had more important things to do. But like all things we want that fixed before reaching stable.
OK, great. Thanks. Just let me know if you would like me to revoke the pull request or leave it as it is for now so you have a record of the issue.
If you're not going to push to that branch just leave it open, otherwise open a separate ticket. Thanks.
I'll leave it open, I will not use this branch for anything. Thanks.
I'm about to push the updated .app.src files for all the projects without the unknown keys anymore. Closing this. Thanks for your patience!
This particular change is in 1cfc4ed. Thanks!
Remove an unsupported key from the .app file