Feature suggestion: Libary part "variant of"

[Dave F]

The library model provides a "derived symbol" that reuses a symbol from a reference library (like the kicad distributed libs) and allows the user to modify fields.  This works great for a hobbyist workflow where you lay out a circuit with placeholder symbols, then fill in the values.

But many users will prefer to work from a curated library of orderable, BOM-able parts, often in a dblib or an http lib.  For these users, the curated fields are valuable and their immutability is a benefit.  But sometimes a symbols tweak, or even a new symbol, is needed for clean layout.  Kicad has no mechanism for preserving the values but changing out the symbols and pins.

It is possible to copy and paste a curated library part and update the symbol locally, but then the derivative part is subject to rot, stagnating while the source part can be updated in the library to add new fields, such as lifecycle status, etc.

I propose a "variant of" library feature, which is the inverse of "derived from".  It attaches the immutable fields from a library part to a user's symbol and pin design.

This is useful in many applications such as:

• Arranging microcontroller, fpga, or buffer pins to match the function of a circuit
• matching a part to the style of an existing design
• breaking a symbols into multiple units (This is often done for simple analog and logic parts, like amplifiers, buffers, flip-flops, but many complex chips may come as a lumped symbol
• Annotating different treatment of the same part in schematic variants, for automatic inclusion of notes in the BOM

I'm working on a patch to implement this.  The behavior is:

• The patch adds a 'variant of'  selector just below the 'derived from' checkbox in the new part dialog.
• The new part can have any name
• The new part cannot mutate any of the source part's parameters, but can add new parameters
• If the variant-of part adds a parameter that conflicts with a parameter in the source part, the source part parameter wins.
• position of the field text does not count as mutation
• the variant part automatically inherits updates from the source on loading (if the source is connected)
• A part place in the schematic is never updated automatically.  A schematic part can be updated from the variant in the library just the same any other part.
• The variant can have new fields as needed.  These are not affected by update of the inherited fields

The change does involve a file format change, not only for libraries, but for schematics, so it's not trivial.  But I believe it would be a valuable addition to version 11.

I am planning to submit a patch, but would be grateful for feedback.

[Seth Hillbrand]

Hi Dave-

Just some quick feedback.

1) The http/db lib already does this.  It is literally one of the features that motivated the dblib development.

2) The term "variant" is already taken.

For the applications you list, variants already allow annotation differences for the same part in schematic variants.  And symbol body styles largely cover the use case where you want alternate geometry and pin layouts for different circuit functions.

Unless I misunderstood your proposal, it sounds like all of your use cases are already covered by existing KiCad functionality.  Could you review the current KiCad v10 behavior and let us know if there are specific functionality points that are lacking?

Seth

    

Seth Hillbrand

Lead Developer

+1-530-302-5483‬

Long Beach, CA

www.kipro-pcb.com    in...@kipro-pcb.com

--
You received this message because you are subscribed to the Google Groups "KiCad Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to devlist+u...@kicad.org.
To view this discussion visit https://groups.google.com/a/kicad.org/d/msgid/devlist/aa1e18bf-18cf-4542-9dbe-14234e3371cbn%40kicad.org.

[Dave F]

Hi Seth,

Thank you so much for taking the time to respond.

I may be missing how the http/dblib does this.  Of course the maintainer of the lib can select any symbol.  But it's not clear to me how a user of a read-only httplib/dblib is able to locally override the symbol without copy/pasting the symbol into the local project, which breaks the connection to the controlled library, losing any updates, and resulting in rot.  That's the specific issue I'm trying to address.

It's very common to need a slight changeup of a provided symbol, but not acceptable to sweep all those local variations back into the controlled library.  In  a company or other forma development setting, the parameters are the critical controlled portion; the symbol may not even be under librarian control; in the case of a library that uses the standard kicad symbols, for example.

For example, My schematic may need the pins of a microcontroller arranged to match my own circuit organization.  There's no reason to sweep that back into the httplib, and unfortunate for me to sever the tie to the httplib to get that convenience.

There are cases in which a note goes with the part, not the schematic.  For example, alternate special mounting method for a common sensor.  Yes, it can go in the schematic, even though it it would not use the variant mechanism there.  But for, say, safety devices that can use the sensor in one of two configurations.  Storing the note and other params with the part is less error-prone than requiring the user to add the extra notes in every new design.

I agree, 'variant of' is not a great choice.  'derived from' is much better, and, in my opinion, much more appropriate to what I am describing than to a shared symbol with different parameters.  In my opinion, the gravity should be on the parameters, not the symbol.  I'm trying to think of a better option.  

Dave

[Jon Evans]

> But it's not clear to me how a user of a read-only httplib/dblib is able to locally override the symbol without copy/pasting the symbol into the local project, which breaks the connection to the controlled library, losing any updates, and resulting in rot.  That's the specific issue I'm trying to address.

The database specifies the path to the symbol to use.  There is no broken connection.  If you update the underlying symbol, updating a database symbol that uses it will get the updates.

>  In  a company or other forma development setting, the parameters are the critical controlled portion; the symbol may not even be under librarian control

That may be your opinion/workflow but I would say it is not common.  In general both the parameters and the symbol graphics are controlled, and this is the workflow supported by database/http libraries.

To view this discussion visit https://groups.google.com/a/kicad.org/d/msgid/devlist/76e89244-704b-42e6-a2ab-7a24982f6510n%40kicad.org.

[Dave F]

> The database specifies the path to the symbol to use.  There is no broken connection.  If you update the underlying symbol, updating a database symbol that uses it will get the updates.

That requires modifying the footprint in the standard footprint library.  That's the exact problem I'm pointing out.  The workflow, as it is, is flawed:

• If you modify the system footprint, then all other designs using that can never update from the library, because of risk of breakage.
• If you modify the system footprint, even if only use that footprint in one design, then you can update that schematic from the library, but you can never safely update your system library without breaking a design.
• There is no clean way to support two different schematics that use arrange the pins of, say, a microcontroller differently.  Any method you choose with the current design loses the ability to update either component, schematic, or library at some level.

By providing a way of creating a new library component that inherits all its parameters from another component, but provides its own symbol, then you can tailor each symbol to each of your schematics and all of them will still get parameter updates safely.

[Dave F]

The specific scenario I have in mind is not esoteric.  I've been working on a project to create an httplib of fully parameterized parts, all generated from scripts, using the kicad standard symbols and footprints.  The httplib's lazy loading makes truly huge libraries feasible, so it's possible to go through, say, a SMT resistor family datasheet and generate thousands of parts, and still be able to search and place them quickly.   Because it's all script-generated, it's robust and easy to expand.  The idea is to (eventually) have an extensive library that anyone can clone and instantly have a huge selection of real, BOMable, orderable parts.  It's paired with the kicad standard library.   

Asking individuals to modify the httplib or the kicad parts defeats the ability to update the httplib and standard libs from the source.

Dave

[Jon Evans]

> That requires modifying the footprint in the standard footprint library

No it doesn't?  We were talking about symbols and now you're talking about footprints, but I still don't understand the point you're trying to make.

> If you modify the system footprint [...]

If you modify a system footprint, period, the correct workflow is to save your modified version into your non-system library (which can be a shared team-managed library)

> There is no clean way to support two different schematics that use arrange the pins of, say, a microcontroller differently.

The clean way is to create two different schematic symbols.  However in my opinion best practice (especially for teams/organizations) would be to not change around the pin layout of symbols on a per-project basis.

[Jon Evans]

That is a perfectly reasonable use case for a HTTP or database library.  In this use case, users *don't modify the symbols or footprints*.  

[Seth Hillbrand]

On Wed, Jul 15, 2026 at 1:39 PM Dave F <dfn...@gmail.com> wrote:

• There is no clean way to support two different schematics that use arrange the pins of, say, a microcontroller differently.  Any method you choose with the current design loses the ability to update either component, schematic, or library at some level.

This is not a true statement.  Library symbols can support multiple body styles.  Pins are indexed by unit and body style, so you can have different body styles with different pin groupings in your library and your layout can choose one or the other.

I think that the upshot you are hearing here is that your proposed change is not fully researched and unlikely to be accepted in the KiCad code base as-is.

I would recommend researching how you might use the existing functionality to meet your needs first and then, if there is a gap, focusing on a smaller, targeted use case to close that gap.

[Dave F]

For example, I place a part from the http lib.  It references the standard library symbol which looks like this:

But my schematic needs this:

How can I keep a live link to all of the httplib parameters, and still use my altered symbol in my project library, without modifying anything in the kicad symbol lib, or the http lib?  If the current Kicad can do this, then I honestly could not find it, but I have looked.  If the answer is: modify the http lib or the std lib, then I think that's a gap.  If the answer is: make your project local symbol, but it can't inherit from the httplib, then I think that's a gap.

[Jon Evans]

>  If the answer is: modify the http lib or the std lib, then I think that's a gap.  If the answer is: make your project local symbol, but it can't inherit from the httplib, then I think that's a gap.

Not quite either of the above.

1) Copy the part into a shared global library (not a project library) that is linked to your HTTP lib

2) Modify the HTTP lib

One idea with using a HTTP or database library is to get *reproducible* results on multiple different computers.  You can't do that by saying you want to allow arbitrary changes to the pin layout of the symbol without touching the library.  If you insist on changing the pin layout of your symbols per-project, the way to do it that doesn't result in broken library links is to just put multiple symbols into your library.

[Dave]

>  If the answer is: modify the http lib or the std lib, then I think that's a gap.  If the answer is: make your project local symbol, but it can't inherit from the httplib, then I think that's a gap.

Not quite either of the above.

1) Copy the part into a shared global library (not a project library) that is linked to your HTTP lib

2) Modify the HTTP lib

One idea with using a HTTP or database library is to get *reproducible* results on multiple different computers.  You can't do that by saying you want to allow arbitrary changes to the pin layout of the symbol without touching the library.  If you insist on changing the pin layout of your symbols per-project, the way to do it that doesn't result in broken library links is to just put multiple symbols into your library.

Yes, the point of the HTTP/DB library is to get reproducible results.  And that is why, if it is necessary to modify the symbol, it's still valuable to get updates to the parameters.  

I think it would be hard to argue that moving some pins around for better schematic flow is not a common or valid need. 

Keeping the system/global libraries standard keeps the schematic portable.  

Requiring the user to copy a part into a shared global library make a schematic less portable, and is a strain on a typical user

Allowing a local-to-schematic modified part that follows parameter updates to the standard library part results in a portable schematic, and is easy for users to understand.

There is already a mechansism that allows the user to create a new part and inherit updates to the symbol.  I'm arguing that the inverse, allowing the user to inherit updates to the httplib/dblib parameters is equally valuable, and in many cases more so.