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*.
On Wed, Jul 15, 2026 at 4:52 PM Dave F <[email protected]> wrote: > 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 > > On Wednesday, July 15, 2026 at 3:39:12 PM UTC-5 Dave F wrote: > >> >> > 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. >> >> >> >> >> On Wednesday, July 15, 2026 at 12:27:36 PM UTC-5 [email protected] >> wrote: >> >>> > 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. >>> >>> On Wed, Jul 15, 2026 at 12:26 PM Dave F <[email protected]> wrote: >>> >>>> 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 >>>> >>>> On Wednesday, July 15, 2026 at 10:56:21 AM UTC-5 [email protected] >>>> wrote: >>>> >>>>> 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 <(530)%20302-5483> >>>>> Long Beach, CA >>>>> www.kipro-pcb.com [email protected] >>>>> >>>>> >>>>> On Tue, Jul 14, 2026 at 2:14 PM Dave F <[email protected]> wrote: >>>>> >>>>>> 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. >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> 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 [email protected]. >>>>>> To view this discussion visit >>>>>> https://groups.google.com/a/kicad.org/d/msgid/devlist/aa1e18bf-18cf-4542-9dbe-14234e3371cbn%40kicad.org >>>>>> <https://groups.google.com/a/kicad.org/d/msgid/devlist/aa1e18bf-18cf-4542-9dbe-14234e3371cbn%40kicad.org?utm_medium=email&utm_source=footer> >>>>>> . >>>>>> >>>>> -- >>>> 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 [email protected]. >>>> >>> To view this discussion visit >>>> https://groups.google.com/a/kicad.org/d/msgid/devlist/76e89244-704b-42e6-a2ab-7a24982f6510n%40kicad.org >>>> <https://groups.google.com/a/kicad.org/d/msgid/devlist/76e89244-704b-42e6-a2ab-7a24982f6510n%40kicad.org?utm_medium=email&utm_source=footer> >>>> . >>>> >>> -- 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 [email protected]. To view this discussion visit https://groups.google.com/a/kicad.org/d/msgid/devlist/CA%2BqGbCDe%3D0CURwWM65LYwg_1DuCLuT4RRDrCkhbkX_j5_4twsg%40mail.gmail.com.
