Home Youtube GitHub

Setting up a Development Environment


#21

Ahh, ok.

I was wondering why is Qt.py downloaded on build, and not just copied into https://github.com/mgear-dev/mgear_dist/tree/master/framework/scripts/mgear/vendor?
Looks like it’ll just download the latest Qt.py, which could potentially break the build.


#22

If I setup an environment where I point PYTHONPATH to the different repositories like https://github.com/mgear-dev/animbits/tree/master/scripts and https://github.com/mgear-dev/crank/tree/master/scripts, then Python will only pick up the first module found.


#23

Hello @Toke_Stuart_Jepsen

Let me intervene on giving some fast clarifications. We have setup mgear python/repositories in order to have everything as separated as possible in order to have a more flexible development env but at the same time everything gets under the same python module on the releasing system.

You can actually append to your python path each individual script folder for each repository and this will work all together because we are using python pkgutil extend_path which makes all matching modules to exist under the same namespace.

What can you do with this? You can either create a dev env in which you are always pointing Maya’s Python path to the released version generated by scons. Or you can actually add into your python path each part of the actually framework repos script folder. On the second option you will need to setup the plugings path yourself as on the first option mGear gets released as a Maya Module but nothing prevents you to manually setup Maya’s python path, plugin path, script path on your own env of maya executable.

Hope this helps a little bit


#25

Ok, I think I’ve found where my issue was.

I have been using https://github.com/mgear-dev as a starting point for its https://github.com/mgear-dev/mgear_dist/blob/master/framework/scripts/userSetup.py (which isn’t anywhere else than there?), so its easier to manage contribution back to the community.
You can have https://github.com/mgear-dev/mgear_dist/blob/master/framework/scripts as a starting path in PYTHONPATH followed by the rest of the repositories’ scripts directories, or the https://github.com/mgear-dev/mgear_dist/blob/master/framework/scripts at the end of PYTHONPATH.

Start of PYTHONPATH
This results in this error:

// Error: ImportError: file C:\Users\admin\Desktop\mgear-environment\bin\mgear_dist\framework\scripts\userSetup.py line 15: No module named shifter.menu // 

Because the mgear module in mgear_dist (https://github.com/mgear-dev/mgear_dist/tree/master/framework/scripts/mgear), gets discovered first and no other mgear module is imported. Can see this when looking at:

print mgear.__path__
['C:\\Users\\admin\\Desktop\\mgear-environment\\bin\\mgear_dist\\framework\\scripts\\mgear']

Solution is to add pkgutil expand_path to this module (https://github.com/mgear-dev/mgear_dist/blob/master/framework/scripts/mgear/init.py). This seems to solve the issue throughout.

Ending of PYTHONPATH
This results in this error:

// Error: AttributeError: file C:\Users\admin\Desktop\mgear-environment\bin\mgear_dist\framework\scripts\userSetup.py line 12: 'module' object has no attribute 'install' // 

Seems like the method/attributes in https://github.com/mgear-dev/mgear_dist/blob/master/framework/scripts/mgear/init.py does not get evaluated.

I don’t know what the solution is to this.


#26

@Toke_Stuart_Jepsen can you please share with me your full mgear PYTHONPATH env variable so that I can try to reproduce this?

Thanks


#27

@Jerome

set PYTHONPATH=C:\Users\admin\Desktop\mgear-environment\bin\mgear_dist\framework\scripts;C:\Users\admin\Desktop\mgear-environment\bin\animbits\scripts;C:\Users\admin\Desktop\mgear-environment\bin\crank\scripts;C:\Users\admin\Desktop\mgear-environment\bin\flex\scripts;C:\Users\admin\Desktop\mgear-environment\bin\mgear_core\scripts;C:\Users\admin\Desktop\mgear-environment\bin\rigbits\scripts;C:\Users\admin\Desktop\mgear-environment\bin\shifter\scripts;C:\Users\admin\Desktop\mgear-environment\bin\shifter_classic_components\scripts;C:\Users\admin\Desktop\mgear-environment\bin\simpleRig\scripts;C:\Users\admin\Desktop\mgear-environment\bin\synoptic\scripts

#28

What is the workflow for making PRs?

Do we merge back to the develop branches or master?


#29

Good question. Right now Master is good. Since we are evaluating/thinking a better workflow with Develop branch.

I had a lot of merge conflicts in the last release with all the difference repos

If you have experience with this, any advice is welcome :slight_smile:


#30

Could you elaborate on this?
Was it when you updated the submodules in mgear_dist?


#31

I was not doing the things right . It was my fault
So I was wondering if there is a better way to manage the structure/repos/branchs


#32

I’ve mostly only had experience with multiple repos from the Pyblish and Avalon project, but we haven’t really got a good way of distributing the whole framework.

We do have a release on each repository with every merge so people can be sure they are using the same version without needing to know the git commit hash.

We have done some experiments with Docker; https://github.com/getavalon/docker, https://github.com/getavalon/docker/pull/53

Dunno if this is any helpful.