Subfolder for Python modules

[looo]

Regarding your suggestion:

- Let third parties simply create packages prefixed with freecad_, so for example freecad_assembly2

that would be an option, and make sense. Especially if the package lands on pypi...
But I think we do not have to (can not) force people to do this.

[simonvanderveldt]

- Prevents future name clashes between FreeCAD's own modules and third party ones

I don't think this will be a problem. Python has this problem too. Pip doesn't solve it. You can easily make two packages with the same package name, but give different package names in the setup.py. This is something the community has to deal with, and I don't see big issues there.

I'd strongly suggest/urge to not include third party packages in your own package/namespace, especially when the fix is so simple.
Naming clashes are pretty annoying and both the debugging of strange errors as well as the loss of independence is not a useful thing to spend your time on.

Regarding your suggestion:

- Let third parties simply create packages prefixed with freecad_, so for example freecad_assembly2

that would be an option, and make sense. Especially if the package lands on pypi...
But I think we do not have to (can not) force people to do this.

Of course we can What we're talking about here is the definition of FreeCAD's module interface. If that says that the package should start with freecad_ otherwise it will not be picked up then that's that

Also it might be an idea to add the option to the Addon Manager to allow it to download from PyPI. PyPI has a very simple API that lists all packages on there, which means it's easy to get all the packages starting with freecad_ from it
Not sure how useful that would be though since one can also just use pip install

[looo]

I'd strongly suggest/urge to not include third party packages in your own package/namespace, especially when the fix is so simple.
Naming clashes are pretty annoying and both the debugging of strange errors as well as the loss of independence is not a useful thing to spend your time on.

If we include the functions, variables, ... from FreeCAD.so (dll) inside of the __init__.py of the freecad namespace, then this could be a problem. But not if we make the FreeCAD.so available via freecad.app. This way we can restrict the freecad namespace as a pure "namespace" and everything added to this namespace are packages. With this a freecad-directory for FreeCAD is the same as a python-directory is for python (eg. site-packages). This is a directory only containing packages.

As I already mentioned, this would be the import structure:

Code: Select all

import FreeCAD as App     ->  from freecad import app
import FreeCADGui as Gui  ->  from freecad import gui
import Part               ->  from freecad import part
import Fem                ->  from freecad import fem

The other option would be to have the FreeCAD.so directly available via freecad.
And there your suggestion to have a second layer make sense.

Code: Select all

import FreeCAD as App     ->  import freecad as app
import FreeCADGui as Gui  ->  from freecad import gui
import Part               ->  from freecad import part
import Fem                ->  from freecad import fem

[simonvanderveldt]

Code: Select all

import FreeCAD as App     ->  from freecad import app
import FreeCADGui as Gui  ->  from freecad import gui
import Part               ->  from freecad import part
import Fem                ->  from freecad import fem

This looks good to me.
The only thing I'm saying is to on top of this not let 3rd parties add to this freecad package and instead simply let them use a prefix + their desired name.

[looo]

But what's the problem. If there is a package with the same name nobody will install this package. If there is another "os" package for python nobody will install it... If there is another part package for freecad nobody will use it...

I really do not see a reason for restricting package-names...

ps.:
Actually placing the same package in Mod and lib/python2.7/site-packages import the one in the Mod directory. Also the initialization is done with the package in the Mod dir. So we can definitely be sure the "core" modules will be first.

[simonvanderveldt]

It sounds like we're going in circles. Not really sure what more to explain honestly.

I really do not see a reason for restricting package-names...

Why wouldn't one do so?

[looo]

I would say, we make a PR for the simplest solution without any name restriction, so everyone can try it. With this implemented in master you can make a 3rd-party extension to demonstrate the name-clashes. I think further discussion won't help.

Maybe also @wmayer or @yorik can have a look at this to give a short statement...

[simonvanderveldt]

I would say, we make a PR for the simplest solution without any name restriction, so everyone can try it. With this implemented in master you can make a 3rd-party extension to demonstrate the name-clashes. I think further discussion won't help.

Maybe also @wmayer or @yorik can have a look at this to give a short statement...

Sounds good. I'll create a PR with just the changes to enable this.

[simonvanderveldt]

OK, I've updated the implementation to just use freecad as a package name.
Also rebased on current master.
Does this look OK? If I'll create a PR for it, initially without updating the modules themselves.
https://github.com/simonvanderveldt/Fre ... ce-modules

[looo]

1. Why removing the pkgutil.exdent_path in freecad.__init__.py? I don't think extending the path is possible this way.
2. I don't know if it is a good idea to move the Arch module to the new directory. better wait with this a bit...

btw.: trying to create a wall in arch already gives an exception:

Code: Select all

Traceback (most recent call last):
  File "/home/lo/anaconda/envs/fc_py2/Mod/Draft/DraftSnap.py", line 1075, in click
    accept()
  File "/home/lo/anaconda/envs/fc_py2/Mod/Draft/DraftSnap.py", line 1085, in accept
    callback(self.pt,obj)
  File "/home/lo/anaconda/envs/fc_py2/Mod/freecad/Arch/ArchWall.py", line 247, in getPoint
    self.addDefault(l)
  File "/home/lo/anaconda/envs/fc_py2/Mod/freecad/Arch/ArchWall.py", line 276, in addDefault
    FreeCADGui.doCommand('wall = Arch.makeWall(base,width='+str(self.Width)+',height='+str(self.Height)+',align="'+str(self.Align)+'")')
  File "<string>", line 1, in <module>
AttributeError: 'module' object has no attribute 'makeWall'