Subfolder for Python modules

[triplus]

A simple alternative is to use a prefix...

Yes some amount of that will i guess always make sense.

P.S. I didn't read in depth the last discussions. I am guessing having pip support as a new possibility (to install FreeCAD Python modules/macros) is nice.

[looo]

how to continue this topic? @simonvanderveldt are you still interested? Have you found a better solution?

to summarize the solutions:

1. simple prefix all files and subdirs (current situation)
2. entry point one level up, already possible (DeepSoic suggestion)
3. simple add a __init__.py and remove from sys.path, (clashes with std python modules eg numpy), already possible
4. import from freecad (allows to place the module at any place in sys.path -> modules can be installed with pip)
5. import from freecad.modules (same as above, but "freecad" can replace the current "FreeCAD")

To me it seems nr.4 is the way to go. There is no proposal which would have avoided all name-clashes. But 4 and 5 minimize them + gives us the opportunity to use pip for installing 3rd-party modules.

[triplus]

Current modules likely won't change in this regard unless somebody invests some serious effort in it. New ones likely will just continue to follow the same convention. Therefore i wouldn't look on this from the perspective we need to resolve something. Instead more like an opportunity to add a new feature. That is pip support. Without having the support pip can't be used to install a FreeCAD module. If support is provided by FreeCAD there is a chance somebody will use it and things can evolve from there on. Anything is possible after. From no real traction to i guess becoming preferred method for installing FreeCAD modules.

[looo]

ok, so we should forget about pip-installable-packages. (at least at the moment)
I will try to port some of the modules to (3). This should not be a big problem if we later want to go to (4) or (5).

[looo]

I tried to port the fem-module but got lost with imports on C++ side, but it seems this is not the same:

Code: Select all

-     Gui::Command::addModule(Gui::Command::Gui,"FemGui");
+    Gui::Command::doCommand(Gui::Command::Gui,"from Fem import FemGui");

Also the place of the shared libraries has to be discussed, as they are not the same for install and build.
install: ${CMAKE_INSTALL_LIBDIR}
build: Mod/.../

Wouldn't it be better to have them in the same place?

[wmayer]

I tried to port the fem-module but got lost with imports on C++ side, but it seems this is not the same:

When recording a macro then Gui::Command::addModule aims to avoid duplicate import statement and puts them on top of the macro while Gui::Command::doCommand doesn't do this.

However, the way how Gui::Command::addModule is implemented it doesn't support importing of sub-modules at the moment. But this can be easily fixed by checking for a dot in the module name. Once it's fixed you can write Gui::Command::addModule("Fem.FemGui") and internally it will split the string at the last dot and write from Fem import FemGui

Wouldn't it be better to have them in the same place?

Yes it makes sense and it will simplify a few things. Like the Python search path we also extend the system path (PATH) by all the module directories.

[looo]

However, the way how Gui::Command::addModule is implemented it doesn't support importing of sub-modules at the moment. But this can be easily fixed by checking for a dot in the module name. Once it's fixed you can write Gui::Command::addModule("Fem.FemGui") and internally it will split the string at the last dot and write from Fem import FemGui

As there are more than two ways to import a module, what about adding a cached option to addCommand?
something like this:

Gui.Command.addModule("import Fem.FemGui", cached=True)

[simonvanderveldt]

how to continue this topic? @simonvanderveldt are you still interested? Have you found a better solution?

My suggestion from the previous page (see quote below) still works, I can invest some time to rebase on current master and make sure it also works with make as well as with make install if there's still interest?

@simonvanderveldt
I think it would be quite said if we can't move forward because of this little difference in opinions.
If that is so, I would say we should concentrate on your first implementation (freecad.modules). To me the flat and your first approach are on bar. While the one offers a simpler structure, the other offers more possibilities. So that is really not a big problem for me. I just want to get this done.

I will create a PR from your first proposed implementation.

Just noticed your PR, running my current code from the CMAKE_BINARY_DIR doesn't work (I believe I mentioned that before, use make install if you want to try it), because I didn't want to bother with figuring out how FreeCAD's custom CMake macros work during prototyping. Assuming the macro's can simply copy files or directories it shouldn't be that hard to fix. I don't mind to update my code so this is fixed and create a PR, shall I do so?
Also, as I already posted, I'm not sure about changing the "entry points" for FreeCAD modules. Would like some feedback from the main contributors on that.

[kkremitzki]

I'm still interested in this subject and wanted to cast a spell of necromancy on the thread. I recently watched this 3h video, David Beazley - Modules and Packages: Live and Let Die! - PyCon 2015 which was very informative and seems like a useful resource for anyone wanting to get the ball rolling on this topic again.

[looo]

I'm still interested in this subject and wanted to cast a spell of necromancy on the thread.

We should definitely work on this as it comes up again and again. https://forum.freecadweb.org/viewtopic. ... 73#p180273

btw thanks for the link. I will try to get through it, but not at once

interesting points so far:
10:35 sys.path
17:05 relative import py2 / py3
24:00 __init__.py
26:00 pep8 class naming, __all__, from . import *
30:00 __all__works a bit odd