It might be worth looking at Maya Modules. They allow you to create encapsulated packages which make it very easy to distribute.
The docs (From Maya 2014 onwards) are quite good around Modules now. The idea is that you have a folder which contains a scripts folder, plugins folder, icons folder etc. You then have a single .mod file which describes the path (as a mininum).
In terms of steering that towards your goal, you could have a distributable library module, and then a set of further modules that you deploy that utilise that. There are a series of complexities you have to be aware of though - such as ensuring that the library is up to date with the toolset. Ensuring backwards compatibility is critical when distributing shared libraries - so if you're not already I'd strongly consider adding some TDD or BDD into your workflow to ensure you're not going to critically block anyone on an older version of the library. Providing you always retain backwards compatibility you could inject a system in your library to self-update via http if a tool initialises it expecting a later version etc.
If you want to avoid all that you could put yourself through a form of 'build/packaging process' whereby you programatically cycle through all the library dependencies and copy them into a subdir of your tool module whilst at the same time renaming it to prevent conflicts. For example:
Your development code base:
In this scenario you have 'sucked' a copy of your library (shared_lib, later renamed to shared_lib_n) inside your tool package and would need to auto-refactor based on the import changes. This can definitely work - and given clean code the refactoring can be done relatively reliably - but its success hangs in the consistency of your code and the strength of your packing process (that you'd need to write) and your level of testability to ensure that all key functionality remains intact in the final package before release.