Longstanding issues: structs & standalone Erlang

[Mikael Karlsson]

torsdag 23 februari 2006 03:15 skrev 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.

Yes, it was a misunderstanding. Sorry, I guess I was to biased on the
Erlmerge solution which seems to solve problems of platform dependency
by compiling the packages on the target.

> ...
> ...
> 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.

OK, I get your point, I think. I agree that it should not be imposed, but
it should be possible pack the system in such a way that you can deploy
it in a proper way. If you would like to do a hot upgrade on a distributed
Erlang system running on several nodes/computers you probably need
a proper package for the ( pure erlang ? ) OTP release handler.

> 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.

Sorry for the noise, but I guess I am biased towards a different type of 
application.

> > 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.

Yes, you are right, but beeing a member of the great Objectweb consortium
you are aware of all the nice ant tasks available to make packages, for
example for the consortiums JOnAS application server. I am even able to run an 
Ant task from my Eclipse environment that deploys the applications on a 
running JOnAS server. I can realize that this may not be a good path for all 
of us, but it may be for some :-)

> 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.

If the performance competition is Java for instance , I think you can 
come far with Erlang without HiPE enabled. I thought you could run  any
Erlang module compiled without HiPE enabled on any HiPE enabled 
platform. Is that not the case ?

> 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.

I won't correct you, it seems I got even more corrected in a later posting on 
this topic.

Nevertheless. I think when you run an Erlang distributed environment you need 
to use the native libraries for distributed deployment and lifecycle 
management. I am still missing a component binding contoller. Coming from 
objectweb, have you thought anything about a ( a'la Objectweb) Fractal 
binding (and attribute) controller for Erlang gen_servers? 

Cheers 
Mikael