# Limit on project inheritance? **URL:** \ **Category:** Ignition Early Access\ **Created:** [November 1, 2021, 10:24am UTC](https://forum.inductiveautomation.com/t/limit-on-project-inheritance/52558 "2021-11-01T10:24:50Z")\ **Posts on this page:** 6\ **Page:** 1
**Author:** ![tordvd](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/tordvd/32/11525_2.png) [@tordvd](https://forum.inductiveautomation.com/u/tordvd)\ **Post date:** [November 1, 2021, 10:24am UTC](https://forum.inductiveautomation.com/t/limit-on-project-inheritance/52558/1 "2021-11-01T10:24:50Z")
Hi, Is there like a limit for how many projects that can be inherited? I mean in the sense that this is slowing down the system, launch times, client behaviour. Or something like this? The reason I ask is that we have multiple libraries. Each library is defined in its own inheritable project. If our customer has 4 different PLC libraries within different brands (siemens/rockwell/ABB etc). global -\>rockwell\_lib1-\>rockwell\_lib2-\>siemens\_lib1-\>abb\_lib1-\>myMultiLibProject ---
**Author:** ![pturmel](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/pturmel/32/3295_2.png) [@pturmel](https://forum.inductiveautomation.com/u/pturmel)\ **Post date:** [November 1, 2021, 12:41pm UTC](https://forum.inductiveautomation.com/t/limit-on-project-inheritance/52558/2 "2021-11-01T12:41:57Z")
You are trying to shoe-horn multiple-inheritance behaviors into a single-inheritance model. Until IA implements the former, you should place all truly globally common libraries in the root inheritable project. other inheritable projects can collect shared resources for subsets of leaf projects, but the “library” concept simply is not feasible. ---
**Author:** ![ryanjmclaughlin](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/ryanjmclaughlin/32/4318_2.png) [@ryanjmclaughlin](https://forum.inductiveautomation.com/u/ryanjmclaughlin)\ **Post date:** [November 1, 2021, 12:45pm UTC](https://forum.inductiveautomation.com/t/limit-on-project-inheritance/52558/3 "2021-11-01T12:45:14Z")
_this_ While technically possible, it will be a mess to maintain, also debugging all those projects in a chain could prove to be a nightmare in some scenarios. If you only care about scripts and truly want “library” functionality, then you can manage the pylibs external to Ignition and just load them to the user-lib folder on the gateway. ---
**Author:** ![tordvd](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/tordvd/32/11525_2.png) [@tordvd](https://forum.inductiveautomation.com/u/tordvd)\ **Post date:** [November 1, 2021, 2:17pm UTC](https://forum.inductiveautomation.com/t/limit-on-project-inheritance/52558/4 "2021-11-01T14:17:26Z")
Thanks for the feedback guys. I forgot to mention that the libraries are only for popups, and “global objects”(object indication). I was thinking that if the structure of the libraries were good. Then this would be feasible. - all templates and popups were segmented in specific folders `libraries/lib01/` - all libraries would be fully segmented(standalone) I would expect these library projects only to have **one** folder in windows (popups), and **one** folder in templates and **one** folder for scripts. I Dont really see the maintenance problematics @ryanjmclaughlin mentioned. Its just that we are delivering projects to multiple customers, and some customers do not need all libraries. Also, if we update the library for one customer, we could simply import it directly to the other customer lib-project. @pturmel, I dont really like it either. But for me it looks like the best solution, but would it not be feasible? ---
**Author:** ![KathyApplebaum](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/kathyapplebaum/32/7261_2.png) [@KathyApplebaum](https://forum.inductiveautomation.com/u/KathyApplebaum)\ **Post date:** [November 1, 2021, 2:49pm UTC](https://forum.inductiveautomation.com/t/limit-on-project-inheritance/52558/5 "2021-11-01T14:49:50Z")
Inheriting from more projects shouldn’t cause any noticeable issues with the system. On startup the gateway will have to scan through all the projects you have, but if each project has fewer resources I wouldn’t expect any noticeable increase in start time. The client sees what we call the “effective project” – a flattened down view of the inheritance, so you shouldn’t see a difference there. There is a small hit on flattening the project, but again total number of resources would be more important than number of projects. But like others have said, I don’t think the chain you described will do what you want. When you want the same chain but without rockwell\_lib1 for another customer, you’ll be having to make rockwell\_lib2a, sienmens\_lib2 and abb\_lib2 and maintain all of those. If you’re happy with that, try it and see how it works for you. ---
**Author:** ![tordvd](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/tordvd/32/11525_2.png) [@tordvd](https://forum.inductiveautomation.com/u/tordvd)\ **Post date:** [November 1, 2021, 3:10pm UTC](https://forum.inductiveautomation.com/t/limit-on-project-inheritance/52558/6 "2021-11-01T15:10:20Z")
Aah I get it now. In my mind one project would have only lib\_b while the other project within the same gateway would have lib\_a and lib\_b. That combo is not possible.(as lib\_b is stuck with lib\_a) I rest my case. Thanks all for the feedback!