-
Notifications
You must be signed in to change notification settings - Fork 715
Auto-update of fp-lib-table by KiCad? #94
Comments
The github plugin will most likely not work in v5. (can't handle one repo for all footprint libs) The intended way to get new stuff to users is via the new library download webside or they need to clone the 3 repos. But here also some manual updating might be needed by the user to get the fp-lib-table updated. Edit: @SchrodingersGat should we remind the packagers that this is the case and they need to include the footprint libs? |
@poeschlr I have reminded them many times and will continue to do so as we approach v5 release! We need to quickly finish the footprints (and symbols) transition :) |
I would be opposed to this idea. We should not be overwriting users
library tables. I for one would not be very happy is the next time I
ran kicad, my library tables were changed. I'm fine with providing a
tool to check if there are updates available for the default library tables.
…On 11/23/2017 11:01 AM, evanshultz wrote:
@SchrodingersGat <https://github.com/schrodingersgat>
Will KiCad v5 auto-update fp-lib-table? If so, then footprint repo
changes can be pushed out to users. Otherwise, they'll be unable to add
or remove libraries.
The schematic has the same issue.
Discussed somewhere here and at
https://bugs.launchpad.net/kicad/+bug/1705291. Here is the root of the
question: If we have two files that capture all current libraries,
whether they're manually- or automatically-generated, why shouldn't the
GitHub plug-in also update those files so the users always has the
latest and greatest. For users who don't want to use the GH libraries,
that's fine, but those that do can be kept updated between KiCad releases.
I realize this isn't a core library issue. But if there are reasons this
can't be done by the library team, or isn't ready to be done, then of
course there's no reason to have KiCad do it. But if all the
infrastructure in the library is ready, and it's a good idea, then it
needs to be raised to the KiCad dev team.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
<#94>, or mute the
thread
<https://github.com/notifications/unsubscribe-auth/AFnmprt0A6_AX3u-hJwCn67cgSK_GnD2ks5s5ZbmgaJpZM4Qo9W8>.
|
Clarification needed: I'm only thinking about users that use the GH libraries. It was written into a paragraph above but could have been missed. A user may self-manage their libraries and that's fine. But if a user chooses to use the GH libraries it only makes sense to me that their lib tables and the libraries themselves are updated without excessive (or any?) effort. So maybe this won't work with the current library structure for v5. I would think that requiring users to manually get and update the libraries is undesirable for every single user. A tool that could check for new libraries and then update both tables and library files would satisfy my request. @stambaughw |
@evanshultz this is an old issue, is it still valid ? Thanks, Joel |
Heck yeah, but I guess it's KiCad dev thing and I didn't seem to be able to communicate well with Wayne on launchpad. If there is a way to use the official library on-demand, like it was on v4, then it would have been nice to make the library tables also update from GH. But that didn't happen. As it is now, KiCad could be more convenient about a situation where the table and files at the path don't match, but that's also something to report to the devs. Closing now. |
@SchrodingersGat
Will KiCad v5 auto-update fp-lib-table? If so, then footprint repo changes can be pushed out to users. Otherwise, they'll be unable to add or remove libraries.
The schematic has the same issue.
Discussed somewhere here and at https://bugs.launchpad.net/kicad/+bug/1705291. Here is the root of the question: If we have two files that capture all current libraries, whether they're manually- or automatically-generated, why shouldn't the GitHub plug-in also update those files so the users always has the latest and greatest. For users who don't want to use the GH libraries, that's fine, but those that do can be kept updated between KiCad releases.
I realize this isn't a core library issue. But if there are reasons this can't be done by the library team, or isn't ready to be done, then of course there's no reason to have KiCad do it. But if all the infrastructure in the library is ready, and it's a good idea, then it needs to be raised to the KiCad dev team.
The text was updated successfully, but these errors were encountered: