Getting imports correct in the leo-as-a-package branch is turning out to be "interesting".
In the interests of sanity, I think leo.py should change to something like runLeo.py--otherwise there is too much possibilities for confusion between the leo *module* created by leo\__init__.py and the leo module created by leo\core\leo.py. In other words, there must be only one possible leo module. This change will one or two of my scripts (and who-knows-how-many of your scripts) but I don't see any good alternative. Here is what I have done recently. If any of you sees a problem with this please let me know asap. 1. The general idea is that we want run Leo from Python\Lib\site- packages. Typically, Python\Lib\site-packages is in sys.path. We do *not* want add Python\Lib\site-packages\leo to sys.path because... 2. We will change all imports from import leoX to import leo.core.leoX. This works provided the leo folder is in the site-customize folder. 3. To *simulate* this arrangement, I have temporarily added leo.repo \leo-as-a-package to sys.path. Thus, the leo-as-a-package folder acts just like the site-packages folder will act when Leo truly *is* a package (that is, when the leo folder truly is contained in the site- packages folder). I am going into exhaustive detail here because imports are very finicky just now. I want to test the following: Requirement 1. Importing Leo as a package will work if the current directory is an arbitrary directory, i.e, the current directory is neither a leo directory nor its parent. Requirement 2. We have got to be able to override the Leo package defined in site-packages. That is, even if Leo is truly installed as a package, we must be able to run Leo from a bzr branch. Python typically adds the current directory to sys.path, so if we cd trunk we should be able to run Leo from the trunk. Indeed, from the trunk 'import leo' will find the module defined in trunk\__init__.py, and import leo.core will find the module defined in trunk\core \__init.py. It is this second requirement that lead me to want to rename leo.py to something else. In short: A: We must rename leo.py. B: We can simulate Leo being a package by having sitecustomize.py place leo.repo\leo-as-a-package in sys.path. C: All imports in Leo, wherever they may be, will use fully-qualified imports such as import leo.core.leoGlobals as g. This should ensure sanity and consistency. All comments welcome. Edward P.S. As yet another piece of the puzzle, C is essential because none of the following statements are equivalent, even if they all refer to the "same" module: - import leoGlobals as g - import core.leoGlobals as g - import leo.core.leoGlobals as g These imports are all different because they put three different entries in sys.modules. The keys in sys.modules are respectively "leoGlobals", "core.leoGlobals" and "leo.core.leoGlobals". I have no idea whether this could be called a bug (I kinda doubt it), but it means that all imports in Leo must use exactly the same scheme. EKR --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "leo-editor" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/leo-editor?hl=en -~----------~----~----~----~------~----~------~--~---
