Could work. Or maybe:looo wrote:Code: Select all
FreeCAD._useNewStyleImport()
Code: Select all
FreeCAD._newModuleImportStyle()
Code: Select all
FreeCAD._removeFromSysPath()
FreeCAD._removeModuleFromSysPath()
Could work. Or maybe:looo wrote:Code: Select all
FreeCAD._useNewStyleImport()
Code: Select all
FreeCAD._newModuleImportStyle()
Code: Select all
FreeCAD._removeFromSysPath()
FreeCAD._removeModuleFromSysPath()
Until then 100 other things will breake, so at some point I think we are allowed to introduce proper importing.P.S. Full migration of the existing modules/macros with some relevance therefore realistically could take a few years.
This is not true. If a module has not used by another module it can savly move towards the new style. As shown this is possible for 0.17 or older. The only thing not available in 0.16 is the function I have added in the commit and the sys.path which points to the ~/.FreeCAD/Mod. But you can always do this by your own. So I see no problems downstream.After you need to take into consideration this fact in your module. When doing the imports. And further if you write documentation on how to use the module from Python you need to provide it in a form it will work for both styles. And you must continue to prefix everything.
Isn't that exactly what we are trying to do? It's all about removing the mod-directories from the sys.path to get rid of the naming issues. But as we can't do this right now, we have to slowly get to this goal. The first step is to give new modules the possibility to use proper imports. (PR)Isn't it a lot easier to just not hard append modules to the Python path like this and instead make the FreeCAD package a namespace package
can you explain this? What is meant by a normal location?and install it together with it's modules to a normal location.
This should be equivalent to adding the locations of FreeCAD modules to FreeCAD.__path__. I don't see why this should be simpler.And then just do a pkgutil.iter_modules("FreeCAD.Modules") to iterate over the existing modules and init them?
Yeah, this is what I meant with my question. If I understand it correctly right now the modules are first added to the sys.path and then a new function is added to let a module remove itself from sys.path again if it wants to. Is that correct?looo wrote:Isn't that exactly what we are trying to do? It's all about removing the mod-directories from the sys.path to get rid of the naming issues. But as we can't do this right now, we have to slowly get to this goal. The first step is to give new modules the possibility to use proper imports. (PR)
The PyMOTW explains it best imho https://pymotw.com/2/pkgutil/, sample code lives here if you want to try it out https://bitbucket.org/dhellmann/pymotw/ ... ?at=masterlooo wrote:I do not really understand what a namespace package is, but using FreeCAD.__path__ gives us the possibility to have everything available under the FreeCAD name-space. And this is quite simple.
can you explain this? What is meant by a normal location?and install it together with it's modules to a normal location.
This should be equivalent to adding the locations of FreeCAD modules to FreeCAD.__path__. I don't see why this should be simpler.And then just do a pkgutil.iter_modules("FreeCAD.Modules") to iterate over the existing modules and init them?
Code: Select all
import pkgutil
__path__ = pkgutil.extend_path(__path__, __name__)
can you give an example for this. What does it mean for the current structure of freecad? Does it mean, we do not have to use a __init__.py?But where should we place the "__path__ = pkgutil.extend_path(__path__, __name__)" then?Note that Python 3.3+ will automatically create namespace packages when no __init.py is present making this even easier.