I set up my tool distribution to be handled in sitecustomize around a
completely portable toolset, only main applications are installed locally,
like maya, mobu, etc..
PyQt, Qt, python and all scripts/plugins live on the server, no local
installs or syncing necessary, tools are live.

to set up a machine a single bat file is run that sets some global
environment variables and maps the network drive.(or maps to a protable
drive taht has a coppy of the tools on it if we need to take it offsite for
a show)

Tools are designed around the imp module. so inside an app (say maya)
switching a show imports the appropriate modules as a tool is run under the
new show without any app restarts.

Standalone pyQt apps are started using a bat file and all pyQt apps are
built following a code template for consistency.

Large changes to tools are versioned up on the server until tested then the
old tools are backed up and the new changed tool takes it's place as the
main tool.

Standard rule on the tools, backward compatible and tools designed around
global usage as much as possible. Not many tools/pipelines are designed to
be single use. mainly just settings for particular projects that the tools
use as defaults for interfaces.

I even use sitecustomize to update users maya.env files - changes to the
env require running maya 2 times to get updates that are done in the
maya.env because of order of loading on the maya side.



n Tue, Jun 5, 2012 at 10:28 AM, zhang jian <[email protected]> wrote:

> Hi,
>
> We are handling such problem as well. The solution is not that good, but
> still usable.
>
> We programmers and tds are using Mercurial to maintain just one copy of
> scripts/plug-ins/py packages, on a centralized server. Those artists are
> loading those things remotely on maya/standalone startup. The idea is to
> make sure everybody on the same page.
>
> We have a maya plugin to config Python sys.path to locate necessary py
> packages, to source mel scripts, to load plug-ins, create menus. so on. On
> each workstation, just all MAYA_PLUG_IN_PATH to locate that config plugin,
> auto-load it will do the magic each time maya started.
>
> For standalone applications, we use the same idea. Most apps are just
> simple PyQt, do not start it directly, start a config tool first, setup
> sys.path, then run the main app. We managed to create a standardized py
> script to do that, to launch a specif app, just run
>
> python configStandalon -a appname
>
> Put it into a bat/sh file, so those artists can use an app by
> double-click.\
>
> zhang
>
>
> On Wed, Jun 6, 2012 at 12:19 AM, Judah Baron <[email protected]>wrote:
>
>> I won't go into a lot of detail right now, but here are some of our
>> highlights:
>>
>> Version controlled distributions so users can sync to update, roll back
>> to escape problematic releases, etc. We use Perforce, but anything is
>> better than nothing here. Syncing also means everyone's system looks
>> similar. We void custom installations and configuration at all costs
>> because it makes maintaining numerous machines more difficult and very time
>> consuming. For instance, our tools do not rely on the version of Python
>> that is installed on the workstation. Instead, we maintain a copy of Python
>> and all of our dependencies in our version control system, and our tools
>> call on these dependencies explicitly. This allows us to have multiple
>> versions of Maya, running potentially multiple versions of Python, at the
>> same time, with [ideally] the same code.
>>
>> Ideal Setup For New Employee:
>>
>>    1. Fresh machine configured by IT with standard studio image as
>>    starting point.
>>    2. Sync to latest release of tools.
>>    3. Run.
>>
>> This ideal setup is actually not just our ideal, but how we really
>> operate. If ever we have an issue with a newly configured machine not being
>> able to run any component, it servers as an indicator that our system needs
>> to be modified to handle such a situation. We still run into problems every
>> once in a while, but it generally has to do with the disk image not being
>> complete.
>>
>> Good luck,
>> -Judah
>>
>>
>> On Tue, May 29, 2012 at 5:43 AM, Alexander Kalychny <[email protected]>wrote:
>>
>>> Hi there
>>> We cg-animation studio with >100 people and now we deep in  major
>>> pipeline cleaning for all departments, and wondering how guys at
>>> major studios  distribute, update ( maybe auto-update?) tools  for tds
>>> and artist in maya.
>>> Maybe using pip / easy_install with your own server serving eggs? or
>>> smth else?
>>> Im interested in tools at all scales and platforms
>>> (windows,linux,osx): from  pyqt small dialog tools for maya, to big
>>> standalone pyqt package with a lot of C++ custom modules
>>> interdependencies..
>>> How you guys approach these kind of problems?
>>>
>>> Thanks
>>>
>>> --
>>> view archives: http://groups.google.com/group/python_inside_maya
>>> change your subscription settings:
>>> http://groups.google.com/group/python_inside_maya/subscribe
>>>
>>
>>  --
>> view archives: http://groups.google.com/group/python_inside_maya
>> change your subscription settings:
>> http://groups.google.com/group/python_inside_maya/subscribe
>>
>
>  --
> view archives: http://groups.google.com/group/python_inside_maya
> change your subscription settings:
> http://groups.google.com/group/python_inside_maya/subscribe
>

-- 
view archives: http://groups.google.com/group/python_inside_maya
change your subscription settings: 
http://groups.google.com/group/python_inside_maya/subscribe

Reply via email to