How are cross-module python dependencies handled in the current build system? If I just %import core.i in misc.i then swig tries to load a module IMP_core rather than IMP.core. Changing the module name to IMP.core in core.i doesn't work since swig declares macros using the name and macros can't have "." in then.
Daniel Russel wrote: > How are cross-module python dependencies handled in the current build > system? If I just %import core.i in misc.i then swig tries to load a > module IMP_core rather than IMP.core. Changing the module name to > IMP.core in core.i doesn't work since swig declares macros using the > name and macros can't have "." in then.
I'm surprised Keren wasn't able to answer this one, because she ran into the same problem a little while ago with Assembler. Yes, it's exactly as you state. SWIG does the right thing at wrapping the modules and all of the C++ inheritance is handled correctly, except for one point - any Python inheritance results in an 'import IMP_core' in the Python code rather than the correct 'import IMP.core', and we can't use "." in the module names for various reasons (another is that I've never seen a DLL or so with "." in the name, and it would probably cause problems somewhere - underscores are almost always used for delimiters, e.g. in the Boost shared objects). Keren currently handles this with a simple sed of the generated Python module to replace IMP_core with IMP.core. This obviously isn't a permanent solution, but I will look into better long term fixes.
Ben
Ben Webb wrote: > Daniel Russel wrote: > >> How are cross-module python dependencies handled in the current build >> system? If I just %import core.i in misc.i then swig tries to load a >> module IMP_core rather than IMP.core. Changing the module name to >> IMP.core in core.i doesn't work since swig declares macros using the >> name and macros can't have "." in then. >> > > I'm surprised Keren wasn't able to answer this one, because she ran into > the same problem a little while ago with Assembler. Yes, it's exactly as > you state. SWIG does the right thing at wrapping the modules and all of > the C++ inheritance is handled correctly, except for one point - any > Python inheritance results in an 'import IMP_core' in the Python code > rather than the correct 'import IMP.core', and we can't use "." in the > module names for various reasons (another is that I've never seen a DLL > or so with "." in the name, and it would probably cause problems > somewhere - underscores are almost always used for delimiters, e.g. in > the Boost shared objects). Keren currently handles this with a simple > sed of the generated Python module to replace IMP_core with IMP.core. > This obviously isn't a permanent solution, but I will look into better > long term fixes. > Thanks. I this case there would have been a circular dependency (misc imports core and core imports misc). Does that add difficulties?
Daniel Russel wrote: > Thanks. I this case there would have been a circular dependency (misc > imports core and core imports misc). Does that add difficulties?
Definitely - that won't work. Can't you arrange for misc not to import core? misc is intended to be standalone, while core is of general utility to everyone, so it's fine for things to import core but importing misc should be discouraged. Sounds like your class should go in core in this case.
Ben
Ben Webb wrote: > Daniel Russel wrote: > >> Thanks. I this case there would have been a circular dependency (misc >> imports core and core imports misc). Does that add difficulties? >> > > Definitely - that won't work. Can't you arrange for misc not to import > core? misc is intended to be standalone, while core is of general > utility to everyone, so it's fine for things to import core but > importing misc should be discouraged. Sounds like your class should go > in core in this case. > The core dependency on misc is just from needing to use the transformation classes. These probably shouldn't stay in misc over the long term anyway. The kernel is probably a more proper place, but actively working on code in the kernel is rather too painful to be considered.
On Dec 3, 2008, at 8:11 PM, Daniel Russel wrote:
> Ben Webb wrote: >> Daniel Russel wrote: >> >>> Thanks. I this case there would have been a circular dependency >>> (misc >>> imports core and core imports misc). Does that add difficulties? >>> >> >> Definitely - that won't work. Can't you arrange for misc not to >> import >> core? misc is intended to be standalone, while core is of general >> utility to everyone, so it's fine for things to import core but >> importing misc should be discouraged. Sounds like your class should >> go >> in core in this case. >> > The core dependency on misc is just from needing to use the > transformation classes. These probably shouldn't stay in misc over the > long term anyway. The kernel is probably a more proper place, but > actively working on code in the kernel is rather too painful to be > considered. Lets decide on a module for the transformation classes - it does not really make since to leave them in misc anyway. Either we'll create a geometry module or put it in core - what do you think?
> > _______________________________________________ > IMP-dev mailing list > IMP-dev@salilab.org > https://salilab.org/mailman/listinfo/imp-dev
Keren Lasker wrote: > Lets decide on a module for the transformation classes - it does not > really make since to leave them in misc anyway. > Either we'll create a geometry module or put it in core - what do you > think?
It's not clear to me why they went into misc in the first place, since they are clearly of general utility. I will move them to core. We can worry about new modules on the other threads.
Ben
Ben - you have enough to do as it is !!! I'll do that :) On Dec 3, 2008, at 9:17 PM, Ben Webb wrote:
> Keren Lasker wrote: >> Lets decide on a module for the transformation classes - it does not >> really make since to leave them in misc anyway. >> Either we'll create a geometry module or put it in core - what do you >> think? > > It's not clear to me why they went into misc in the first place, since > they are clearly of general utility. I will move them to core. We can > worry about new modules on the other threads. > > Ben > -- > ben@salilab.org http://salilab.org/~ben/ > "It is a capital mistake to theorize before one has data." > - Sir Arthur Conan Doyle > _______________________________________________ > IMP-dev mailing list > IMP-dev@salilab.org > https://salilab.org/mailman/listinfo/imp-dev
participants (3)
-
Ben Webb -
Daniel Russel -
Keren Lasker