installation: co-existence of several Invenio sites on the same box

[tiborsimko]

Originally on 2010-08-20

0) Sometimes it is interesting to install more than one Invenio instance on the same physical box. When the instances are lightly used and their codebase does not change often, e.g. for demo purposes, then a simple technique is use another module name such as ithaca instead of invenio when installing the second instance, like this:

$ cd /usr/local/src
$ tar xvfz cds-invenio-0.92.0.tar.gz
$ mv cds-invenio-0.92.0 ithaca-0.92.0
$ cd ithaca-0.92.0
$ find . -type f -exec perl -pi -e 's,invenio,ithaca,g' {} \;
$ mv po/cds-invenio.pot po/ithaca.pot
$ configure --prefix=/opt/ithaca --with-weburl=ithaca.polito.it [...]

see: [[http://cdsware.cern.ch/lists/project-cdsware-users/archive/msg00686.shtml]]

1) Some Invenio sites use such a technique and expressed interest in having this more automated inside the Invenio codebase itself. The purpose of this task would be then to introduce a new configuration parameter such as:

$ ./configure --instancename=ithaca

that would perform the above steps behind the scenes, ideally altering installation files only, keeping codebase the same.

2) An alternative to this simplistic technique is to set up PYTHONPATH properly for the two instances, e.g. see Ferran's approach: [[https://groups.cern.ch/group/project-cdsware-users/Lists/Archive/DispForm.aspx?ID=549]]

[romanchyla]

Originally on 2010-08-20

The 2) link is not accessible (access denied)

Another alternative is to have all 'changeable' values in the config and have invenio read them at runtime. This is different from the current situation, because if system is 'really portable' one can change few lines in the config, move the installation into a different folder, adapt apache config, and voila!

I generally miss the purpose of make/make install in the CMS system like Invenio -- it just makes things very complex and everything what make does can be done much more easier with python alone or by changing requirements (for instance, bin/* files have shebang which makes it tied to the configured python interpreter, where there could be just one entry point that simply executes the other bin applications, there is more of those, generally, if any file is there hardcoded in the source, it makes it non-portable). The make mechanism basically allows Invenio to do away with the current situation and not being forced to restructure files a bit more.

[tiborsimko]

Originally on 2010-08-20

Replying to [comment:1 rchyla]:

The 2) link is not accessible (access denied)

The members of the mailing list should be able to access it. Just use the email identity with which you are subscribed to the list.

(Due to the e-groups system used at CERN, the archives cannot be fully open to anonymous guests. I planned put them onto gmane.org after renaming the list (cdsware->invenio).)

I generally miss the purpose of make/make install in the CMS system like Invenio -- it just makes things very complex and everything what make does can be done much more easier with python alone

We use autotools from the times Invenio had WML, Python, PHP, Common Lisp. Now we have only Python and Common Lisp. We could indeed abandon autotools more easily now and port the functionality to something like SCons, but there are more urgent things to do. I don't think the configure && make && make install process is that complex.

(for instance, bin/* files have shebang which makes it tied to the configured python interpreter, where there could be just one entry point that simply executes the other bin applications, there is more of those, generally, if any file is there hardcoded in the source, it makes it non-portable).

Python interpreter is not hardcoded in the sources. The sources use @PYTHON@ that is replaced by the wanted value from the --with-python configure option. Usual autotools stuff.

[tiborsimko]

Possible in Invenio 1 via above technique or via virtual environments.