Longstanding issues: structs & standalone Erlang

[Romain Lenglet]

Mikael Karlsson wrote:
> onsdag 22 februari 2006 10:11 skrev Claes Wikstrom:
> > Bengt Kleberg wrote:
> > > i try to voice the opinion that configure, make, make
> > > install is not easy for everybody.
> > > i could be wrong.
> >
> > Yes,
> >
> >
> > /klacke
>
> No,
> I would not be that sure that this is wrong.
> It is easy if you have the tools installed, but that may not
> always be the case. 

Here is the same misunderstanding again...
The proposal was *not* to use ./configure ; make ; make install 
for deployment / installation, but for *building packages*, 
which in turn can be deployed and installed.

It is OK to create a new pure-Erlang packaging / deployment 
system, but 1) application developers should not have to deal 
with creating such packages, and 2) any application should be 
easily packagable by a packager using any packaging system.
I want to emphasize on the latter point: 2-1) packaging should be 
made easy to packagers, 2-2) the choice of a packaging system 
should be let free to packagers (no packaging system, e.g. a 
"pure-Erlang" packaging system, should be imposed by 
developers).

To make this possible, a common form for source packages provided 
by developers must be defined, e.g. by including a configure 
script and a Makefile in every source tarball.
(Fredrik, you are right when writing that the configure script 
must not necessarily be generated by GNU Autoconf...)

Nothing should prevent a packager to take a source Erlang 
application, to build it by running the provided configure 
script and Makefile rules, and to create a user-installable 
package using any "pure-Erlang" packaging system you want: in 
this scenario, end users of the package would not have to 
install anything else than Erlang.

But please understand that this is not the only packaging 
scenario. Another packager should be able to take the very same 
application in the same source form, build it by running the 
provided configure script and Makefile rules, and create a 
Debian package that can be installed by end users using only the 
Debian package installation tools (hence, not requiring any 
"pure-Erlang" package installation tool like above).

In the two packaging scenarii above, packagers can make sure that 
they have the right tools installed on their own systems to 
create installable packages (yes, I believe that any packager 
can make the effort to install a variant of Make on its system, 
at least).

> And there is a point in having a pure
> Erlang system (like REPOS ?) that can deploy "pure" erlang
> packages.

Yes, just like there is a point in having a pure Ruby system that 
can deploy "pure" Ruby packages, and a pure Java system that can 
deploy "pure" Java packages, and a pure Perl system that can 
deploy "pure" Perl packages, and a pure Python system that can 
deploy "pure" Python packages...
(Sorry for the ironic tone... ;-))
I am just wondering how you can manage / upgrade applications on 
a system with such a proliferation of incompatible packaging 
systems?

Really, I am not against this idea. I just say that a pure Erlang 
packaging system should not be imposed, and applications should 
be delivered by developers in source form with a configure 
script and a Makefile, and not in compiled form as a pure Erlang 
installable package. Creating installable packages is the job of 
a packager, and there may be many packagers of a single 
application, for different systems with different packaging 
systems.

I am very sorry to repeat myself, and to decrease the signal / 
noise ratio of this mailing list, but I have the impression to 
not be understood.

> See the other thread:
	> http://www.erlang.org/ml-archive/erlang-questions/200602/msg00
>369.html
>
> Suppose 80 % of Erlang applications are not "contaminated" by
> C-code :-) then it would be nice to have a way to deploy them
> on an installed Erlang base system without having to think
> about other infrastructures. There should be some benefit of
> running on top of a VM. Java/Ant is another example of this.

Ant is a build system, not a packaging system.

And even packages containing binary native code could be deployed 
using a packaging system in pure Erlang, there is no problem 
with that.
One issue would be to be able to have several versions of every 
such package, one for every architecture / system, and the 
system should be able to choose and install the right version on 
a system. But this can be solved.

Even with "pure" Erlang packages, that problem of native binary 
code would arise one day, with the spread of Hipe: a packaging 
system will have to offer different packages with modules that 
contain binary code generated by Hype, for every architecture 
supported by Hipe.

> Why not make deployment apps like erlmerge sensitive about if
> there is a Makefile or an Emakefile (or none) and decide which
> route to take.
>
> The problem with deployment on Erlang, as I see it, is that it
> is not possible to add new applications to releases, and that
> they all have to go into the erlang root library. It would be
> nice if Erlang could have a secondary library path that was
> searched too, meaning that you could deploy applications in an
> own library without having to do code:add_path{a,z} for
> everyone of them. And making it easy to upgrade your Erlang
> base system without affecting your own additions.

You want the equivalent of Java's CLASSPATH environment variable. 
Why not?!

But I believe that a CLASSPATH-like (why not call it MODULEPATH?) 
is of no help to manage packages. Normally, if a packaging 
system is able to install a package, it should also be able to 
uninstall and upgrade it automatically without having users to 
struggle with a PATH environment, and even if the packaging 
system had installed files in a common directory tree.
Correct me if I am wrong.

-- 
Romain LENGLET