I initially tried with Github for Windows, but got this error message:
Then I tried manually with git, but only got as far as cloning:
PS C:\Users\admin\Desktop> git clone git@github.com:mgear-dev/mgear_dist.git
Cloning into 'mgear_dist'...
git@github.com: Permission denied (publickey).
fatal: Could not read from remote repository.
Please make sure you have the correct access rights
and the repository exists.
You need to use SSH. Sorry, this is the way that is configured.
Alternatively, You can do this manually by creating your own version of mgear_dist
Ohh, right. Anyway of removing that requirement?
I honestly haven’t used SSH before (maybe I should?), and it seems like it might be a hurdle for newcomers that wants to contribute.
Alternative repositories might just confuse things even more 
I’ve got mgear_dist cloned now, but do you need to build every time you make a change?
What is your development environment?
We are using Scons with Excons extension: https://github.com/gatgui/excons
The info is here: https://github.com/mgear-dev/mgear_dist/blob/master/BUILD.md
it is really easy
Sorry, I may not have been very clear.
I was wondering what your development workflow is? Do you for example make some changes to the python code and rebuild?
I appreciate that you would have to rebuild when working on the plugins, but if most of the time its just python code you wouldn’t need to rebuild.
Scons with Excons extension, not only rebuild the compiled C++ plugins, but also copy/deploy the .py files in the final distribution structure.
every time a change is made in a python file/files you deploy on a temporal “release folder”. but only modify files are copied.
Also, Excons have different targets, I.e: only python files or C++ or all. So the deploy can be very granular
Check the documentation, when you know the basics. it is really easy and flexible to use
Also, don’t forget to check the sConstruct configuration file
Probably this file is the most useful to learn how it works 
So when you are developing, is this the workflow?
more like this:
I’m currently exploring a development environment for mGear, and was wondering about the mgear python module in each repository like https://github.com/mgear-dev/shifter/tree/master/scripts/mgear.
Why are the repositories in a submodule called mgear?
to keep the folder structure consistent. This helps in some situation for debugging since everything is split in several repositories
if you check the init.py will see this
# imports
from pkgutil import extend_path
# extend mGear python package by adding the current module
__path__ = extend_path(__path__, __name__)
in the future with python 3.x this will be not needed
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.
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.
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
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.
@Toke_Stuart_Jepsen can you please share with me your full mgear PYTHONPATH env variable so that I can try to reproduce this?
Thanks
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
What is the workflow for making PRs?
Do we merge back to the develop branches or master?
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
Could you elaborate on this?
Was it when you updated the submodules in mgear_dist?