mgear-dev / mgear_dist

mGear v.3.x.x distribution repository
http://www.mgear-framework.com/
MIT License
184 stars 53 forks source link

mgear_dist: Create new distribution structure #17

Closed jdrese closed 5 years ago

jdrese commented 5 years ago

Due to how mgear_dist is growing it would be good to have the structure inside mgear_dist to be a little bit clearer and simpler.

@mgear-dev/developers I will create a test for this and will let you know when you can check it out. If you already have some comments please shoot

miquelcampos commented 5 years ago

@jdrese this other issue comment is related to this issue: https://github.com/mgear-dev/mgear_dist/issues/16#issuecomment-429154035

miquelcampos commented 5 years ago

Hi @jdrese Following up with our conversation, I have been researching about the new structure and how to organize the mgear packages

regarding the use of pkgutil

from pkgutil import extend_path
__path__ = extend_path(__path__, __name__)

I would like to use namespace packages like is defined in https://www.python.org/dev/peps/pep-0420/ This was the way I was talking but didn't remember exactly since never used it before. I was thinking maybe is the same as extend_path, but looks like is a new way and make obsolete the previous pkgutil.extend_path() Please check it and let me know what do you think.

Thanks!

jdrese commented 5 years ago

Hello @miquelcampos

Thanks for the research. Seems interesting. I will give it a try then and will get back to you with more information next week.

jdrese commented 5 years ago

Hello @miquelcampos

So after checking the documentation page I have to say that the idea of using pkg_resources rather than pkgutil seems kind of nice specially because of how they work with charging the modules. pkgutils will extend/load the modules depending on the order they got added into the sys.path and this in some dependency cases can lead into problems (I actually recall having those at nWave at some point so we had to cheat creating specific loading orders to have dependency modules been loaded at certain point)

pkg_resources solves this by doing the namespace of the python package in a more elegant way which even require one less init file per module as needed in the pkgutil.

That been said the problem is that MayaPy does not come with pkg_resource. This is because (if I am not mistaken) Maya devs removes from their Python interpreter some of the buildin python modules to avoid issues of messing up with the site-packages without knowing what you are really doing as this can mess up maya.

For now I am going to do the changes with pkgutil and we can start discussing whether or not we should then add the pkg_resources python lib as part of mgear? do not think this is such a goo idea but it is totally possible