breaking apart INSTANCE_HOME.
Hi folks, Since we started configuration and installation geddon on Zope 2 (which has resulted in Zope 2.7), we've made a number of improvements in the flexibility of file placement behaviors: - You can specify in the config file where you want your lock and pid files to be placed. - You can specify in the config file where you want your filestorage files to be placed. - You can specify in the config file where you want each log file to be written. - You can specify in the config file any number of Products directory paths and these will be knitted together into the Products pseudopackage. This is good, because it makes Zope much friendlier to some filesystem hierarchy standards which require that you don't put library and volatile data in the same place (e.g. the Linux FHS). But it is still a bit monolithic. You need an instance home directory, which must contain (at least) these two directories: import Extensions I propose that we add two more options to the config file: import-directory extensions-directory These would both be multikeys which specify some number of directories that contained importable zexp files and external methods, respectively. This would allow us to not require any fixed instance home directory. Instead, each path required by each subsystem is specifiable by itself in the config file. I'm sure that utilizing these options in the config file will break things that rely on having a monolithic INSTANCE_HOME such as products that attempt to do something like "import_dir = os.path.join(INSTANCE_HOME, 'import'). So I propose that the stock Zope instance home install continue to follow the old pattern (where everything is installed into a single instance home directory), but we provide the advanced config file options for roll-your-own packagers and advanced users. I would like to do the same thing for the software home, but I haven't thought much about it yet. - C
Chris McDonough writes:
I propose that we add two more options to the config file:
import-directory extensions-directory
I'd like to suggest that we call these "imports" and "extensions", to be parallel with the "products" multikey. For products, we use the specified directories to add to the Products package, but that makes sense given that the base Products package is a required component. For imports and extensions, we should consider using the specified directories *instead* of the default. This is easy enough; if the directories are given as relative directories, they should be resolved relative to config.instancehome; the schema can then include the defaults and very little new code will be needed.
I'm sure that utilizing these options in the config file will break things that rely on having a monolithic INSTANCE_HOME such as products that attempt to do something like "import_dir = os.path.join(INSTANCE_HOME, 'import').
Any product that does that will prove fragile eventually. We just need to make sure the core doesn't do anything like that. ;-)
So I propose that the stock Zope instance home install continue to follow the old pattern (where everything is installed into a single instance home directory), but we provide the advanced config file options for roll-your-own packagers and advanced users.
This sounds like a really good plan to me! -Fred -- Fred L. Drake, Jr. <fred at zope.com> PythonLabs at Zope Corporation
On Fri, 2003-07-25 at 10:30, Fred L. Drake, Jr. wrote:
Chris McDonough writes:
I propose that we add two more options to the config file:
import-directory extensions-directory
I'd like to suggest that we call these "imports" and "extensions", to be parallel with the "products" multikey.
Yup, that sounds better.
For products, we use the specified directories to add to the Products package, but that makes sense given that the base Products package is a required component.
For imports and extensions, we should consider using the specified directories *instead* of the default. This is easy enough; if the directories are given as relative directories, they should be resolved relative to config.instancehome; the schema can then include the defaults and very little new code will be needed.
Actually, both of these directories have historically worked in much the same way as the Products package does. A software home may have (actually currently must have) an "import" directory. Zope currently slurps various TTW "examples" from a zexp file in the software home import directory. I'd really like to dump this dependency, but it would take a bit of work. The Extensions directory... errr.. this should probably not be in a software home anymore. I can't think of anything that would break were it to not be there anymore (besides products that depend on the physical layout of the software home, which shouldn't exist).
I'm sure that utilizing these options in the config file will break things that rely on having a monolithic INSTANCE_HOME such as products that attempt to do something like "import_dir = os.path.join(INSTANCE_HOME, 'import').
Any product that does that will prove fragile eventually. We just need to make sure the core doesn't do anything like that. ;-)
Personally, I think we should just hardcode '/home/fred/zope/import' into the core as the import directory and be done with it. ;-) - C
Chris McDonough writes:
Actually, both of these directories have historically worked in much the same way as the Products package does.
Ok, well, that's still not hard to do; we just add the bootstrap directories to each of the lists once we've read the config.
A software home may have (actually currently must have) an "import" directory. Zope currently slurps various TTW "examples" from a zexp file in the software home import directory. I'd really like to dump this dependency, but it would take a bit of work.
Ah, that's right. I keep trying to forget about that. One approach may be to use the import mechanism but not the import search mechanism for that. So there's still a .zexp file in the software, but it's not part of the general import/export support.
The Extensions directory... errr.. this should probably not be in a software home anymore. I can't think of anything that would break were it to not be there anymore (besides products that depend on the physical layout of the software home, which shouldn't exist).
So this one doesn't present a problem. The default list will only include the Extensions in the INSTANCE_HOME, and configuration will override that if something else is desired.
Personally, I think we should just hardcode '/home/fred/zope/import' into the core as the import directory and be done with it. ;-)
That's fine with me. At least it won't be accessing *your* imports directory. ;-) -Fred -- Fred L. Drake, Jr. <fred at zope.com> PythonLabs at Zope Corporation
On Fri, Jul 25, 2003 at 09:52:14AM -0400, Chris McDonough wrote:
- You can specify in the config file any number of Products directory paths and these will be knitted together into the Products pseudopackage.
Sounds good. One thing to watch out for - this needs to be tested with CMF, specifically with the FilesystemDirectoryView product. FSDV does not (as of zope 2.6) find its filesystem content if it is anywhere other than under lib/python/Products or $INSTANCE_HOME/Products. It is the only product I've tried that doesn't work anywhere else on $PRODUCTS_PATH. -- Paul Winkler http://www.slinkp.com Look! Up in the sky! It's UGLY-HAIRDRESSER! (random hero from isometric.spaceninja.com)
Am Freitag, 25. Juli 2003 15:52 schrieb Chris McDonough:
I propose that we add two more options to the config file:
import-directory extensions-directory
This is a VERY good idea. And allow import to be made from an installed product similar to the way external scripts work. And let it find its extension automatically. So we could we could import the file myImport.zexp that resides in Products/MyProduct/import as MyProduct.myImport -- mit freundlichen Grüssen Robert Rottermann www.redCOR.ch
participants (4)
-
Chris McDonough -
Fred L. Drake, Jr. -
Paul Winkler -
robert