[Vienna-pm] mehrere versionen eines modules gleichzeitig benutzen

[peter pilsl]

peter pilsl wrote:
> 
> ich hab ein module und das ist mal fertig und geht in die production. 
> gut.  nebenbei möchte ich das module am gleichen rechner aber 
> weiterentwickeln ohne am tag 10x den productionserver zu schiessen.
>  
> *zusatzfrage* für domm und andere mod_perls : hab ich eine chance, das 
> auch unter mod_perl hinzukriegen. vor allem, wenn das am gleichen apache 
> lauft? development hab ich meist eh nicht unter mod_perl laufen, aber in 
> der endphase dann halt doch.
> 

vielen dank für alle antworten. Ich hab jetzt eine gute, einfache und
hoffentlich auch funktionierende Lösung gefunden, die ich für
interessierte hier lang und chaotisch skizzieren will:


A) auf der seite der module

In allen verwendeten Modulen hab ich bei der devel-version das
Makefile.PL geändert, so dass DESTDIR mein neues perlmodule-root
festlegt. Damit kann ich auch bei der devel-version einfach mit make und
make install arbeiten und muss nicht bei jedem make das DESTDIR anfügen
und mit schlimmen Folgen rechnen, wenn ich es mal vergesse.

WriteMakefile(
     'NAME'              => 'goldfisch::search2',
     'DESTDIR'           => '/data/apache/knowledge/sandbox/bin/perllib',
     'VERSION_FROM'      => 'search2.pm', # finds $VERSION
     'PREREQ_PM'         => {}, # e.g., Module::Name => 1.1
     ($] >= 5.005 ?    ## Add these new keywords supported since 5.005
       (ABSTRACT_FROM => 'search2.pm', # retrieve abstract from module
        AUTHOR     => 'pilsl at goldfisch.at') : ()),
);

Wichtig dabei ist, dass es reicht das Makefile.PL in den "Hauptmodulen"
zu ändern. Die Submodule folgend dann automatisch, wenn man ein
richtiges MANIFEST hat und auch die submodules immer nur über das
hauptmodule testet und installiert.

das Ändern von Makefile ist aus meiner Sicht nicht so gut, weil
irgendwann braucht man doch ein "perl Makefile.PL" und dann wird das
Makefile wieder überschrieben.

Ich habe in meinem konkreten Fall vier Hauptmodule (ala goldfisch::tt2)
und da waren die Makefiles.PL schnell geändert. Wenn ich die untermodule
(ala goldfisch::tt2::init) auch alle hätt ändern müssen, hätt ich mir
wahrscheinlich ein script geschrieben dazu.

Beim Kopieren der Module aus der devel-version in die production darf
man das Makefile halt nicht mitkopieren und distributionpackages sollte
man halt aus der production-version erstellen.


B) auf seite der aufrufenden Anwendungen

hier hab ich den Riesenvorteil, dass ich alle Module aus einer einzigen
perl-applikation aus starte und nach dem lesen von domms paper hab ich
auf "use lib" gesetzt.

use lib
'/data/apache/knowledge/sandbox/bin/perllib/usr/local/lib/perl5/site_perl/5.8.5';

und das wars. @INC "vererbt" sich offenbar auf alle geladenen module und
somit funktioniert das bestens und extrem einfach.

das mit dem BEGIN-block und den if-abfragen, wie von thomas
vorgeschlagen muss ich mir erst anschauen. Steht da der hostname schon
in ENV ?  Cool wärs, weil dann müsst man beim wechsel von devel auf
producation gar keinen source mehr ändern.


C) zusätze:

i) push(@INC) ist in meinem Fall keine gute Lösung, weil ja die
production-version eh auch in @INC steht, weil die im standardpfad ist,
den ich nicht rausnehmen kann, weil da ja alle andern module liegen, die
ich so brauche.
wer direkt mit @INC arbeiten will, müsste also ein "unshift(@INC)"
verwenden, aber ich finde use lib wesentlich einfacher und cooler.

ii) für mod_perl funktioniert das ganze nicht so einfach, weil die
packagenames ja gleich bleiben und mod_perl daher einmalig die version
(devel oder production) lädt, die als erste gewünscht wird und dann auch
an die andere version ausliefert.
Ein eigener apache kommt nicht in Frage. Es laufen schon drei apaches
und die applikation ist *extrem* speicherhungrig. Einen vierten, der
auch wieder ein paar 100MB will, verträgt mein Server leider nicht mehr.
Wenn ich mal ganz viel Zeit habe, werde ich mir anschauen, ob man
legaler- oder illegalerweise einen packagenamezusatz auch im Makefile
festlegen kann.

iii) das only-module würde ein versions-logistig voraussetzen, die über
ein tägliches tar czvf aller module hinausgeht ;)

iv) bei mod_perl ist imho "." nicht Teil von @INC.zumindest in meiner
1.99.9999999999999999 (oder so)-version. hab aber schon einige zeit
nicht mehr upgedated.


danke an alle nochmals,
lgp


ps: ganz rein theoretisch hab ich also jetzt ein kleines büro mit
internet/wlan/klo/beamer/dachterasse/wienblick für etwaige vorträge von
bis zu 10Leuten (im sommer auf der terasse mehr). da ich aber selbst eh
nie zeit habe, zu vorträgen zu kommen, müsste das bei interesse über
domm organisiert werden (der einzige, den ich kenn und somit der
einzige, dem ich den schlüssel aushändigen würde ;) -  aber vielleicht
würd ich dann ja mal kommen :)