Two of the classes I’m working on for the vertical studio pipeline tools are called MayaProject and MayaProjectManager, stored in the (slightly ambiguous) pipeline.pymel.project.py
I’m pleased to say that the initial versions of these should be ready in time for tomorrow’s dailies. Both classes are the result of a feature request, nevermind a long time frustration of mine, that most beginning Maya users don’t understand referencing and project space (Workspace), and it the case of undergraduate, particularly group projects, thus cause time-consuming local referencing, fosterParent situations, end up rendering personal work to quota-enforced network shares, etc.
MayaProject allows you to define an expected project space based on a name (used mostly for pretty-print and GUI messaging) and a root. This root, naturally, is the location of workspace.mel.
MayaProjectManager allows for several of these expected projects to exist without allowing the roots to be duplicated. This root
is* should always be calculated on userSetup, seeing that particularly in the case of network shares or Dropbox, one may need to consider user environment variable expansions, check internalVar locations, or deal with external drives.
Why, you might ask, do we need a redundant record of workspaces if Maya handles this all internally? The simplest explanation, as stated previously, is that MayaProject is an account of an expected workspace.
Given the current workspace, the current scene filepath (the path of the file currently open in Maya), and an expected workspace, we can deduce a handful of typical scenarios useful for prompting users to check whether or not they are in the correct project space.
Note: much of this runs on the assumption that all files are stored below the root location of workspace.mel. If this is not the case, the current checks are less accurate, albeit occasionally helpful nonetheless
For example, if my currently opened file is beneath my expected project space, but my project is not set, I may need to change my project. In this case, a popup would offer to open Set Project… for the user or automatically set the project and reopen the current file for you. While the latter is convenient, I’m more a fan of the former, because it educates users about project space.
Similarly, if the currently open file is outside of an expected project space, but the project is set to the expected project space, then the user may be working on a desktop file that needs to be moved to the appropriate share, or may have forgotten to change their project to a personal or default project. A prompt to automatically change to the default workspace or open Set Project… is given to the user.
There’s a lot that can be done with this simple setup for users who are new to maya and don’t have a pipeline with a launcher to set all of their environment variables for them ahead of time. While current situations don’t require a very robust MayaProjectManager for multiple expected MayaProjects, I’m still enjoying evaluating and iterating it as an educational exercise if nothing else.
Spring Break is within the next week, so I may post again about the hooks I am currently utilizing, as well as show some screenshots/screencasts of the script in action.