Hi Joe, Thanks. I also imagine that the global, unified invenio loader would help a lot, together with modules being organized into packages and not as files (modules) inside the big invenio package.
I think the symlinks is not the best solution, because then you would not be able to run several instances of Invenio using different code-bases (unless edits of the global entry poitns are made). And the remove/replace an existing installation with a new installation is what i am trying to avoid. In my situation, I have solved the problem by using virtualenv -- which is a very good tool, but I was wondering if there were other ideas for virtualenv, I have to do: virtualenv something cd something cp -R /opt/cds-invenio/lib/python/invenio ./ the step, which is bothering me is the duplication of the whole invenio tree when I only need to touch one module (needless to say, I am doing this with already installed invenio) other than that, I see no easy way (1 week ago I faked invenio/__init__.py just to be able to provide my own, different invenio.intbitset -- one module -- and I gave up, because there are some 400 .py files in lib/python/invenio... to import) Best, roman On Thu, Aug 26, 2010 at 6:30 PM, Joe Blaylock <[email protected]> wrote: > 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 > > >
