We use apt to manage all our software at our startup, and we like being able to manage components from a heterogeneous set of languages in a uniform way. In other words, some of our software is in Erlang, some is not, and the apt (plus erlrc) lets us treat them similarly. One might guess that I would be against an Erlang-specific packaging solution such as erlware.
Not so! We need erlware and I love it.
At Yahoo we had a proprietary package format that nobody outside Yahoo used. However we could algorithmically convert any CPAN package to our internal package format, so in effect, we had access to all of CPAN. Analogously, companies might use rpm or deb or something else entirely; but by releasing all Erlang software in a standard form, it should be possible to transduce. Right now, when we get stuff from the universe, we end up repackaging them for debian and placing them into our private package archive. Everybody does things slightly differently so it's difficult to generalize this process.
Furthermore, there are exciting benefits to having a single place to look for open-source Erlang software which enforces project quality standards and provides a cross-platform way to start playing around with Erlang.
Subscribe to:
Post Comments (Atom)
1 comment:
That is actually interesting that you love erlware even though you have your own packaging system. :-)
I actually prefer erlware for developing and your packaging solution for releasing and installing in production.
I wish I could have the best from both worlds and I would love to see the Erlang community to capitalize efforts in a single packaging system, like you say.
Post a Comment