Hi Roman, This is indeed a good question, and the answer I've typed below is rather unfocused. I hope it makes sense.
I don't think it has a very satisfactory answer. For myself, I would either have multiple installed instances of Invenio, and multiple source checkouts to go with them (as with http://invenio-software.org/ticket/253) or I would just completely remove and replace the installed version of my site using as script similar to the one I attached to http://invenio-software.org/ticket/256. (I have a nicer version of that if you'd like it.) Actually I'd probably go this second route, because I already have the script and I'm lazy. The two minutes it takes my machine to rebuild and reinstall are two minutes I would be happy to spend fetching tea. I drink a lot of tea. I agree that better packaging and namespacing would help a lot. I wonder if it wouldn't be possible to simply have several configured, installed versions of cds-invenio like: * /opt/cds-invenio-normal * /opt/cds-invenio-patched ...etc... and then get different package imports by manipulating the symlinks in site-packages? I can imagine testing different versions serially by just changing the symlink itself. I could also imagine, though, having everything testable in parallel by having every invenio module start with an import like: from invenio_globals import * and then having invenio_globals be a module that's not in /opt, so it can be subverted by changing your PYTHONPATH, and its contents are something like: import invenio-version-12-with-rocket-skates as invenio ...so that you can have different sets of things just by changing what 'invenio' refers to in any particular instance. For that matter, I wonder if you can solve your problem by manipulating the PYTHONPATH, and making sure that there is some 'invenio' that appears in it before the site-packages version? I'm sorry I can't be more help. Good luck! Joe On Thu, 2010-08-26 at 02:24 -0700, Roman Chyla wrote: > Hi, > > How would you go about running different versions of a module (say > bibclassify) that depends on invenio core? (assuming the module is > standalone, and the functions of the invenio core are ok for all > versions). > > I am in a funny situation where the old version has this kind of import: > > try: > from bibclassify_engine import output_keywords_for_sources > except ImportError, err: > sys.exit(0) > > try: > from invenio.bibclassify_daemon import bibclassify_daemon > except ImportError: > #.... > > The first block is relative, but the second block will import invenio > and whoops, we suddenly have a mix of new and old bibclassify modules > -- the only option, it seems, is like removing invenio link from > site-packages (btw, this global link is a source of other > difficulties, one machine cannot have several invenio installations > without additional layers of hacking - see also > http://invenio-software.org/ticket/253 - I believe we shall use rather > PYTHONPATH and egg-links to accomplish the same thing without > sacrifizing flexibility) > > Yes, my problem is very much related to the namespaces, packages and > modularity (that being an outstanding topic of discussions), but can I > do something else than edit the different version of the modules I > want to test now? How would you swap modules inside invenio for a > quick testing? > > Thank you for tips, > > roman
