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 ther...

simonvanderveldt wrote:For the initial issue there's already a PR to fix the path of the temporary workdir https://github.com/gentoo/gentoo/pull/4048

FYI this has been merged/fixed

For the initial issue there's already a PR to fix the path of the temporary workdir https://github.com/gentoo/gentoo/pull/4048 This also kind of answers the question about old ebuilds, just get it from the git repo, in the case of FreeCAD, this directory https://github.com/gentoo/gentoo/tree/master/...

@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...

I'm sorry, but I'm not going to add it to this PR. Like I said it isn't necessary to address the issue that this topic is about: Making sure there can't be clashes within FreeCAD's own modules by making them into proper Python modules. Also, as I explained before I'm not comfortable contributing so...

Like I said, if I make a PR it will be without the changes to the modules, they can/will be updated one by one after that. Didn't get that, sorry. np :) I'm also looking into if/how things could be made backwards compatible. To ensure that a module which depends on the old imports will still work. ...

1. Why removing the pkgutil.exdent_path in freecad.__init__.py ? I don't think extending the path is possible this way. Correct. This isn't necessary, since this change currently only affects FreeCAD's own modules and they are all distributed together in the same directory. 2. I don't know if it is...

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

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 thi...

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

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

Why wouldn't one do so?