Effective structure of code libraries is a subjective thing, specific to studios. In general I would say if you have more than one tools developer they are absolutely crucial. I can’t imagine developing anything without having a common library of useful code we’ve developed in the past, and refined over time.
Offhand I would recommend against putting project names in your library structure. You hope that code will survive to be used more than one project, right? Projects come and go, and having their names baked into your code will be quickly inaccurate, and irritating.
I’m unclear what you mean by “…centralized in one directory.” The example you list already shows at least three levels of subdirectories, “projectname”, “maya”, “rigging”, etc. In any case, subpackages (subdirectories) are a vital part of any Python code library, so absolutely use those to partition things into more specific functionality as the tree gets deeper. How granular you get is up to you, really. We sometimes start with a module, watch it grow over time, then split it up into multiple modules and/or subpackages later once it gets unwieldy. This requires some changes to client code, so you want a structure that minimizes that kind of thing. A small example from our studio-wide Python library (off the top of my head):
vlib
vlib.com
vlib.devkit
vlib.devkit.xbox
vlib.devkit.ps3
vlib.log
vlib.os
vlib.perforce
vlib.ui
vlib.ui.widgets
vlib.ui.widgets.spin
vlib.ui.frame
… etc.
I’m also unclear what you mean by “non python lib script”. Do you mean compiled C modules, like “spam.pyd”? If so, there’s no reason you can’t put those alongside Python modules, since the import syntax is the same, “import whatever.spam”.
To your idea of putting all tool-specific code in the same tree/package structure… I would be very wary of doing that. How to build studio-wide code libraries and how tools are distributed are two different beasts, and it’s hard for me to see how the same solution would work effectively for both. Think of it this way… as you’re writing code for a tool, you start by writing some general code that could be useful in several tools. That could go into the shared library, sure. But eventually you’re going to be writing code that’s very specific to your particular tool. If you also put that code in the same library (even tucked away in some low subpackage) you’re expanding that library and making it harder to find truly common code later. That’s a crucial feature of any library… being able to find existing code in it very easily and quickly. Filling it up with tool-specific code seems very risky to me, and if your tools developers can’t find the common code quickly they will just write it themselves, and you’re back to having similar but non-shared code everywhere.
The key question when writing code, as far as where to put it, is “Is this code potentially usable by another programmer for another tool?” If the answer is yes, then put it in your shared library. If not, and it’s specific to your tool, put it with the tool. If you have a larger tool that needs many Python modules, give it its own little library, but distribute it with that tool.
On the flipside, I would also be skeptical that one tool distribution method will be effective for every single tool. Whether you distribute it via a library like you propose, or some other single method, odds are you’re going to cook up some tools later that don’t fit well with that, and need to be distributed another way. Especially if you deal with outsourcers or other sites.
Again, these are pretty subjective things. Your studio has to find something that fits. Hope this helps.
