If what you're looking for is customisability of folder structure on a per-project basis, then have you considered working with schemas? I.e. pre-defined levels of each hierarchy onto which your code relies.
There are hints towards how this could work here. https://github.com/shotgunsoftware/tk-config-default Although I would favour a slightly more data-driven approach, schemas are resistant to maintenance failures and are very simple to customise; usually in the form of a YAML file or template hierarchy. Ultimately however, anything pre-defined is bound to hit a level of scale where maintenance outweigh any savings made. On 9 May 2014 11:02, Fredrik Averpil <[email protected]> wrote: > Thanks for your feedback, guys. > It's good to hear the mostly positive feedback towards this virtual folder > structure idea. > > The logic behind everything is indeed made into a library, or rather > python modules. Nuke and Maya imports the shared module (which is heavily > focused on navigating the virtual folders) and then they import their > app-specific module (tools and scripts to prevent the need to dive onto the > disk structure). Same goes for the "standalone mode" which runs directly in > your OS. An admin module allows for automated archiving or reviving of > archived projects. > > Regarding optional maintenance vs required maintenance, we are already in > the required maintenance mode. It's just that this is about developing the > company to support certain projects along side archviz/commercials in the > very same folder structure. I would like to avoid building two structures > demanding two versions of the same tool. > > So my main concern is really if we were to e.g. move away from Maya in > favor for Modo ... or maybe wanting to utilize Nuke Studio ... or Katana > ... what will happen then? > These apps I am guessing are heavily reliant on folder structure on disk. > Perhaps it is possible to customize their behavior in regards to creating > folders and files on disk into my "flat" disk structure and so this won't > be an issue. But I think this is what scares me the most. But right now it > looks like we're going to gain a lot from this. So I think it's worth a go. > > > Fredrik > > > > -- > You received this message because you are subscribed to the Google Groups > "Python Programming for Autodesk Maya" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > To view this discussion on the web visit > https://groups.google.com/d/msgid/python_inside_maya/CAD%3DwhWOrcZW24osm2adfsjS%3D4aBnqWG0QSKQpcDBqRmusDQ1Rw%40mail.gmail.com<https://groups.google.com/d/msgid/python_inside_maya/CAD%3DwhWOrcZW24osm2adfsjS%3D4aBnqWG0QSKQpcDBqRmusDQ1Rw%40mail.gmail.com?utm_medium=email&utm_source=footer> > . > > For more options, visit https://groups.google.com/d/optout. > -- *Marcus Ottosson* [email protected] -- You received this message because you are subscribed to the Google Groups "Python Programming for Autodesk Maya" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/python_inside_maya/CAFRtmOCq9-swT1gfD2LJsTBqDcCgtbxGmBNFsHG8ryrcBCND_A%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
