A problem with a lot of packages is that manufacturers often don’t agree on the exact dimensions, each datasheet containing different footprints for packages that have the same name. There is an interesting discussion here: IPC footprint naming correct? - Page 1
The current solution is to just make footprints that work well enough for most devices, some standardized and some determined by looking at a lot of manufacturer datasheets and figuring out a common value that should work well for most devices. Unfortunately a LOT of packages are not standardized.
An alternative solution would be to take only what is really the common denominator between same packages of different devices: the arrangement of leads, their style(gull-wing, no-lead etc.), the shape of the package etc. and leave the precise dimensions and number of pins as variables. This parametric package family definition could then be used in the device creation process where a user would select the component and the package family along with the parameters specific to this device: pin count, pitch, pad size, courtyard protrusion etc.
This could also later be useful if for example you wanted the size of courtyards to depend on configured fabricator capabilities, if something like that is planned for the future.
Another side benefit would be that the package library would be much smaller, instead of myriad TSSOP packages each with a small difference in the digits somewhere in the name so you have to strain your eyes to find the right one, there would be just one TSSOP family and one HTSSOP family and so on.
Potentially 3D models could also be generated from parametric packages.
I don’t know how realistic this suggestion is, but I wanted to share it nonetheless.
Welcome to the world of packages It is really terrible and I feel absolutely lost in this topic as we have to eat what crap packages the industry creates…
I understand the idea of parametric packages, but my current opinion is that it makes things way more complex – too complex for my vision to make LibrePCB an easy to use EDA. I think if you prefer this flexibility, you need to look for other EDA tools (I guess horizon-eda supports parametric packages).
I don’t want to say this will never be implemented in LibrePCB, but at the moment I think this is not a goal of LibrePCB.
One problem is for sure that the whole complexity of generating packages would need to be part of the software, and needs to be written in a more difficult/“dangerous” language like C++ (or requires to embed a script interpreter, another additional complexity). And the generator needs to be of very high quality since it is production relevant. Our current solution has the advantage that we can use a very easy, modern language (e.g. Python) to generate the packages, and LibrePCB just needs to read simple, non-parametric packages. And quality is less critical, since we can always review the diff when re-generating files in our libraries.
horizon eda does not support what I am suggesting, it has something called parameters for packages but it’s very limited and does not do what I described above. In fact I don’t know any EDA that has a solution to this.
I think it’s possible to have package families without introducing a lot of complexity if you sacrifice the user interface. My approach would be to embed a small interpreter for a DSL that is just powerful enough to generate packages, it does not need to be turing complete so it can easily be fully memory-safe and termination is trivial(can’t loop forever and hang LibrePCB.) The complexity of such a language can be minimal and you can just import the script when creating a package family and not have any kind of editor inside librepcb. Of course the downside is that it’s difficult to use for end-users who can’t do programming, but if most of the common package families come with the base library they won’t need to use it. Then all that is left is to create read-only packages behind the scenes when devices are created using package families.
There is one caveat though which is that if footprints are allowed to be more custom to the use-case and part like this, then in cases where you could have gotten away with a unified footprint it becomes a bit more annoying to exchange parts for equivalents in case of availability or price differences.
I have spent a lot of time studying language design so if you like I would make an attempt at coming up with something neat but if you say you’d never merge something like this anyway I won’t waste any more thoughts on it.
After 10 years of experience in developing LibrePCB, I learned that even the simplest things (like some GUI logic) regularly cause nasty bugs not found by testing and thus get released to end users so my feeling for complexity might be different than yours Even if the initial implementation of a feature is easy, maintaining it over many years can be hard as well. For example migrating it to new technologies (e.g. Qt6, higher C++ standard or so) – or often the backwards compatibility (resp. file format upgrade procedure) is a pain (if we create a DSL, of course it shall not break with every new feature added in future).
That’s actually the main reason why I’m not convinced such a feature really makes sense. In the end, only a very small percentage of users would understand and use that feature. Anybody else just uses the existing packages or create their own manually. But this workflow also works with our standalone generator, just a bit less convenient.
I really appreciate your offer and your initiative regarding this topic But I have to admit I’m not convinced that such a feature follows the vision of LibrePCB, so at the moment I don’t see any chance to merge such a feature – sorry about that.
Please don’t get me wrong. Generally I like your idea, most probably I would be a user of it. But I’m a fan of simplicity and want to keep LibrePCB easy to use. In addition, our time is very limited (because of the limited finances of LibrePCB) so we need to priorize features very carefully. Even if you would provide an initial implementation, I don’t know if you will also maintain it over the next 5-10 years. If not, all the maintenance tasks end up on my desk…
Let’s go back a step and think about the problem such a generator intends to solve. From my point of view, the main problem is that our libraries are still missing many packages, and the contribution workflow is a hassle until now (both with and without generator). So my approach is to focus on simplifying the contribution workflow first. Hopefully this helps to make our libraries more complete. If not, we can talk again about this topic
It is really terrible and I feel absolutely lost in this topic as we have to eat what 
Even if the initial implementation of a feature is easy, maintaining it over many years can be hard as well. For example migrating it to new technologies (e.g. Qt6, higher C++ standard or so) – or often the backwards compatibility (resp. file format upgrade procedure) is a pain (if we create a DSL, of course it shall not break with every new feature added in future).
But I have to admit I’m not convinced that such a feature follows the vision of LibrePCB, so at the moment I don’t see any chance to merge such a feature – sorry about that.
