Ughh, the current libraries are a mess

I am not sure if it will stay that way though.

They will definitely not stay this way - the submodule debate is in the past :slight_smile:

2 Likes

Do you think it would be possible to add an index file to the repo that lists each file and a hash like SHA-2 or similar? I can write the code for it. An update of any file in the repo would require updating this (automatically generated) index file.

What would the purpose of this file be?

To synchronize a repository, file by file, with the local library files. If an index file’s hash has a different value than the local file’s hash, then that file should be scheduled for download.

1 Like

Isn’t that what git is for?

2 Likes

Git does maintain sha1 hashes of the file’s, but I don’t know how to retrieve them from github. I know how to retrieve a file using HTTP from github. Was trying to bypass using an installed version of git or a separate python library install.

Edit to add: “Git does not support downloading parts of the repository. You have to download all of it.”

But I think we can simulate this behavior (downloading parts of a repo) using GitHub.

Why would you want to create a unique SCM system within a Git? Why would you not rather use Git? I mean it is ok for personal use, but for open projects long term maintenance is a factor and Git will stay for long time and it will be actively developed.

Github has a svn api which allows for downloading single directories/files.
This has already been discussed on the mailing list.
More details read the complete communication:
https://lists.launchpad.net/kicad-developers/msg30892.html

2 Likes

Fossil-SCM also allows for this and integrates with Git as well (and offers bugtracking, wiki and a built in web server ui) - rather than an reinventing the wheel :slight_smile:

Is this an alternative to github or would this integrate in our current github infrastructure?

maybe there are some useful info here:

I hope no one minds asking this question here: but why has no one just moved all the footprints into a single repo already in preparation of a v5 release?

It seems like a bit of a chicken and egg problem where no one can use the new repo because it doesn’t exist, and it doesn’t exist because no one can use it. Wouldn’t the major step be just putting it out there to start with? Or is there a process that is needed before this can happen?

This may be documented somewhere else, and I haven’t been able to find it (I’ve been trying to catch up on all the reading on the dev list, github and this forum)

Because we still support v4. We will move them as soon as a v5 release date is in sight. (If the devs take too long a v4.0.8 release might be added. They don’t plan to have it but it might happen.)

As soon as we move the footprnts to the new repo the support for v4 will be stopped. (No new pull requests on the old repos will be accepted.)

4 Likes

Thanks for answering my question :slight_smile: So when the move happens, you would remove the old repos - would this affect older versions of Kicad? Would you see there being a transition period of maintaining both repo formats at all?

I can understand not wanting to try and maintain both at the same time as people would get confused where to check in new fps etc

The old repos will stay. But they will be frozen.
Otherwise kicad 4 will stop working.

3 Likes

@HiGreg I have found something that would help the reviewing process. Automating Silkscreen-Pad clearance is a good way to help. Please have a look at https://github.com/KiCad/Connectors_Hirose.pretty/pull/22

Thank you!

1 Like

I’ll take a look. I have implemented that check in KiPadCheck with pcbnew python. I still am trying to decode the library scripts’ footprint import/parsing structure so I can do the same check for the library scripts.

2 Likes

I have not dealt with those scripts so I cannot help you, sorry.

Anyways I want to thank your effort. If I find anything else that may help I will try to fordward it to you. I think improving the scripts could help solve the library contribution bottleneck.

Reading the comments about scripts and plugins to manage the libraries raises a question in my mind: if library management is so difficult and important, why not dedicate a specific piece of software to it? Much like Eeschema and Pcbnew have distinct and dedicated purposes, why not let a specific piece of software manage the libraries?

This would make it easier to manage downloads, versioning, locations, types etc. And give the space to do it in a more concentrated manner. It could possibly still work with the existing software as long as locations of libraries is passed correctly. It could also bypass a lot of cruft involved in backwards compatibility…

Thoughts?

1 Like

I would also suggest integrating KLC as a “DRC” in the schematic/footprint editor. It would be nice to check the libs from the editor.

1 Like