That's true, so maybe it's a TLOB. I don't think you can merge two different STEP files and get a coherent result though. The versioning only needs to be done at the file level. It's a moot point I guess, there is probably nothing as easy and powerful as git/github.
Using the github API is not really a practical option for fine level access, the API is severely rate limited (10 accesses per minute) and only slightly better if you have login credential, which we would not want to mandate. The SVN access method has performance issues too.
I think a native git plugin is a better option, and also to avoid github specific APIs (other git servers are available ).
Understandably there is push back on that idea, I'm not keen on cryptic archives either. The problem for KiCad at startup is that there is a mass of files, with no index, which may not even be valid data. So that means scanning the whole set to see what is valid data and index it. The advantage of an access tool is that it can update indexes and do validation, so KiCad can start up super-quick with a complete index of valid data.
The other question in my mind, is how to handle "user packages"? I would like to be able to "register" packages with KiCad, so it knows where they are without a lot of platform specific path mangling.
If you use Python, you probably use pip or similar to add remove/packages, so the process can be quite lightweight. The files can also be flat and text, so you could still go in and fix things with a simple text editor, or maintain via simple scripts.
Let's agree on that! I've been trying to move towards the same idea. I think it can be implemented across platforms, but I'm not really sure. There are obvious packaging implications, some distros are strict about user data.
Anyway, it would be really nice to define KICAD_DATA_ROOT and then have everything in there.