Igor Package Installer
Fri, 03/13/2009 - 10:39 pm
This sounds like a great idea. Something like Synaptic Package Manager on Debian/Ubuntu but for Igor. Howard, could you specify what sort of problems you think would arise if this was not implemented directly in the Igor source? If they are not insurmountable maybe it is worth trying it as a normal Igor user project since it seems like the interest is there for development.
I started to write a simple Igor package loader a couple of years ago. The goal was just to create shortcuts from a package folder for procedure and help files. The first problem I ran into is how to make the package available to the end user without actually loading the package. This is desirable because the user may have dozens of packages on his hard drive but does not want all of their procedure files loaded all of the time.
For WaveMetrics packages this is solved via the WMMenus procedure file (which is now an independent module so you must execute "SetIgorOption IndependentModuleDev=1" to see it). WMMMenus.ipf is installed in the Igor Procedures folder all the time. It adds menu items to various menus which load packages. The packages are not loaded until the user chooses the menu item. Thus with just one procedure file, the user has menu access to many packages.
There is no equivalent to WMMenus.ipf for user procedures. In order to add a menu, a user procedure must put a procedure file in Igor Procedures. If the user has dozens of packages available that means dozens of procedure files in Igor Procedures.
Thus what is required is a way for a package to add a menu item without being loaded. This would require that Igor look in a well known place for some configuration file that would specify the package loader menu item. This requires a new feature inside Igor.
Digression - Igor Pro 6.1 adds the "Igor Pro 6 User Files" idea which provides the well-known place. Choose Help->Show Igor Pro 6 User Files. You can access this location using SpecialDirPath. - End Digression
Another problem is that you have to quit and restart Igor to load XOPs. I have had on my to-do list to eliminate this requirement but it has never reached the top of the list.
Another problem is closing procedure files in order to replace them with a newer version. Since you can't close a procedure file while procedures are running, this can be done only via Execute/P. This therefore means that you have to run some procedure that calls Execute/P, let the procedure finish so that the Execute/P gets serviced and then run some other procedure to replace the package procedure files, let the second procedure finish so procedures can be compiled, and start a third procedure to launch the package. This is too kludgy and fragile for my taste.
This is just what comes to mind with five minutes of thought. I suspect if we were to implement this internal to Igor it would lead to many changes within Igor itself.
I suspect that you would want changes to Igor to accomodate the package installer. This would drag us little-by-little into the project and we might wind up doing it ourselves anyway or wind up with a hybrid that is kludgier than a built-in package installer would be. So rather than add pieces of the puzzle little-by-little, I prefer to wait until we have the time to think it out in advance.
Having said that, if you want to take a crack at it, more power to you!
Something like Synaptic Package Manager on Debian/Ubuntu but for Igor.
If I were to do this, I would study Synaptic Package Manager to see what can be learned from or leveraged off of it.
I'm not sure what happens on either platform if one tries to overwrite xops or procedures that are currently open because Igor is open.
You get an error.
This project would be best done as a collaboration as we could develop a more rigourous method together.
You could set up a code snippet on IgorExchange which would be not code but a description of how the installer would work. This could be revised by multiple people like a wiki.
However, I do get Howards point. Something built into Igor would have less dependencies (easthttp, zip) and would therefore be less likely to break. Plus the rules of how packages would be created, etc, would be better adhered to by the community.
I agree. But if you do try to build an installer, I think it is important to think about the structure of a package and try to define something that covers most of the bases and is flexible from the start.