Re: [Kicad-developers] GitHub Plugin (my nemesis)

For what is worth, I strongly support this standpoint! :-) Am 06.10.2017 um 15:33 schrieb Oliver Walters: > Wayne, > > Thanks for the clarification - this discussion is getting a bit > sidetracked I feel. > > We will operate under the assumption that the footprints will be in a > single repo,

Re: [Kicad-developers] GitHub Plugin (my nemesis)

On 10/6/2017 9:33 AM, Oliver Walters wrote: > Wayne, > > Thanks for the clarification - this discussion is getting a bit > sidetracked I feel. > > We will operate under the assumption that the footprints will be in a > single repo, without using submodules. > > Any tools that can or will be

Re: [Kicad-developers] GitHub Plugin (my nemesis)

Wayne, Thanks for the clarification - this discussion is getting a bit sidetracked I feel. We will operate under the assumption that the footprints will be in a single repo, without using submodules. Any tools that can or will be developed for managing KiCad libraries are a secondary

Re: [Kicad-developers] GitHub Plugin (my nemesis)

On 10/6/2017 5:43 AM, Rene Pöschl wrote: > On 02/10/17 11:37, Simon Küppers wrote: >> I am no expert, but this question is out of the scope of this thread.. >> For downloading, gut applies compression anyway. >> >> I respect the people having slow Internet lines.. However as shown a >> few posts

Re: [Kicad-developers] GitHub Plugin (my nemesis)

On 02/10/17 11:37, Simon Küppers wrote: I am no expert, but this question is out of the scope of this thread.. For downloading, gut applies compression anyway. I respect the people having slow Internet lines.. However as shown a few posts backwards, the whole footprints and symbol library is

Re: [Kicad-developers] GitHub Plugin (my nemesis)

Sorry, I was only talking about wrapping the 3D files which can be 100KB to 10MB large. The other files are small enough. On Mon, Oct 2, 2017 at 2:38 AM Simon Küppers wrote: > I am no expert, but this question is out of the scope of this thread.. For > downloading, gut

Re: [Kicad-developers] GitHub Plugin (my nemesis)

Is it possible to keep the 3d models ZIPed or RARed on disk and KiCAD unpacks them on the fly as needed/used during the session/etc? I am seeing 10x reduction in size when I pack the files whether they are 7.5MB or 120KB, both were reduced to 750KB and 10KB respectively. That's a lot of space

Re: [Kicad-developers] GitHub Plugin (my nemesis)

Am 02.10.2017 um 06:14 schrieb David Godfrey: > Bernhard hit the nail on the head here. > For normal Users, ALL of the git functionality should be hidden behind > basic KiCad GUI features. A "normal" user doesn't need any git functions. He expects to have a working solution if he is using KiCad

Re: [Kicad-developers] GitHub Plugin (my nemesis)

On 02.10.2017 07:00, David Godfrey wrote: > [..] > Don't Forget that not all of the world's internet connections are FAST. > While it might seem a good idea from the librarians perspective to have > everything in a single repo, IT ISN'T a good idea at all if you happen to be > on > a slow

Re: [Kicad-developers] GitHub Plugin (my nemesis)

Hi Oliver, An important note before I get to other responses. Don't Forget that not all of the world's internet connections are FAST. While it might seem a good idea from the librarians perspective to have everything in a single repo,

Re: [Kicad-developers] GitHub Plugin (my nemesis)

On 29/09/17 01:53, Bernhard Stegmaier wrote: Just my 2 cents… I have seen some projects using submodules (open source and in my company). I have seen lots of problems and complaints (… doesn’t compile …) just because normal users or even normal

Re: [Kicad-developers] GitHub Plugin (my nemesis)

I completely understand Oliver's view on maintaining every individual repo even if they are submodules of a kicad-footprint repo. Even from an a user perspective (which is clearly easier than the maintainer one), I like knowing what progress is being made, so I'd like to subscribe for updates of

Re: [Kicad-developers] GitHub Plugin (my nemesis)

Just my 2 cents… I have seen some projects using submodules (open source and in my company). I have seen lots of problems and complaints (… doesn’t compile …) just because normal users or even normal developers (being no git experts) didn’t sync all submodules correctly. Thinking of how many

Re: [Kicad-developers] GitHub Plugin (my nemesis)

I'd try to start with the simpler structure of having all the libraries as subdirectories of the same git repo. That doesn't mean that we could eventually add support for submodules, (for anyone that wants to make use of it)... But I agree that from the point of view of the librarians it's a

Re: [Kicad-developers] GitHub Plugin (my nemesis)

Simon, David, Thanks for the synopsis of your idea David, there are certainly some advantages to using the submodule approach. Is it github compatible? Simon, yes git-submodule is compatible with github. I have a test repository here - https://github.com/kicad/kicad-footprints - this contains

Re: [Kicad-developers] GitHub Plugin (my nemesis)

Thanks for your detailed description. I think it is a nice way to go. However two remarks: Does it simplify the maintenance of the kicad library by the librarians? Is it github compatible? If not, we would need to find another platform to host the libraries. If I look for git submodule, there

Re: [Kicad-developers] GitHub Plugin (my nemesis)

+1 also It allows a company to start with the libraries at some point and keep them consistent (by forking) and they can easily cherry pick changes or do wholesale merges with their changed libraries, as they desire.  And for a casual user who just uses things, "as is" it will just work. On

Re: [Kicad-developers] GitHub Plugin (my nemesis)

+1 on this approach, to me this is the obvious way that it should be done. However, my opinion is not important, I'm not a contributor. :) On 9/27/2017 8:37 PM, David Godfrey wrote: Hi All I have to agree with some of the other posters, why not use git as it was intended? Specifically I

Re: [Kicad-developers] GitHub Plugin (my nemesis)

Hi All I have to agree with some of the other posters, why not use git as it was intended? Specifically I think the following makes sense. - Keep the multiple repositories, this helps when a company only wants to make certain sets of libs available to it's staff - Have a master

Re: [Kicad-developers] GitHub Plugin (my nemesis)

On 23/09/17 20:51, Thomas Kindler wrote: The other suggestions were quite surprising to me -- Github API, downloading individual subdirectories as .zip, abusing subversion (gasp), gitslave (last updated 2012), etc. would be a big hurdle and WTF for new KiCAD users. Sorry for the late response.

Re: [Kicad-developers] GitHub Plugin (my nemesis)

Hi Thomas, > So it's not worth the hassle IMHO as shallow clones don't allow to generate > pull-requests without unshallowing them first. Yes, it is possible without unshallowing as the server-side (github.com) fork into which you are pushing is a full clone, and the shallow history that you

Re: [Kicad-developers] GitHub Plugin (my nemesis)

On Sat, September 23, 2017 21:01, Simon Küppers wrote: > [..] > > Maybe it would be a good way to implement two git repos, one for > footprints and one for 3D models (and a third one for schematic symbols..). > That is 3 repos to maintain instead of more than some dozens > as it is right now.

Re: [Kicad-developers] GitHub Plugin (my nemesis)

Your message got me thinking. Maybe it would be a good way to implement two git repos, one for footprints and one for 3D models (and a third one for schematic symbols..). That is 3 repos to maintain instead of more than some dozens as it is right now. Then I would agree with you, I would

Re: [Kicad-developers] GitHub Plugin (my nemesis)

Hi all! After reading all the other messages, here are my two cents: The KiCAD installer should just offer to do a full git clone of kicad-footprints and kicad-libray (which will be split into 3D, templates, etc. for the 5.0 release as I understand). A full clone takes 3.8 GB. A shallow clone

Re: [Kicad-developers] GitHub Plugin (my nemesis)

I think we are all still not sure where we are heading and what problems we actually want and need to solve here. But the most critical problems have already been outlined in this thread. See the first posts. Am 23.09.2017 um 16:47 schrieb Carsten Schoenert: > Am 23.09.2017 um 16:29 schrieb

Re: [Kicad-developers] GitHub Plugin (my nemesis)

Hi, A small slightly tangent suggestion: Can we somehow remove the need to mention every .pretty repo in the fp-lib-table? Instead, can we just give a list of folders in which in turn will contain .pretty folders. This will permit automatic addition of libs if more .pretty libs are created in

Re: [Kicad-developers] GitHub Plugin (my nemesis)

Am 23.09.2017 um 16:12 schrieb Kevin Cozens: > On 2017-09-22 03:44 AM, Oliver Walters wrote: >> that would certainly work but svn has the advantage of being able to >> pull selective directories from GitHub. > > As an FYI, you can use git to deal with an SVN repo using git-svn package. And this

Re: [Kicad-developers] GitHub Plugin (my nemesis)

Am 23.09.2017 um 16:29 schrieb Simon Küppers: > Just to be clear, currently, the plugin does not use GIT. It uses a > proprietary GitHub Interface. > > I also checked out gitslave and similar stuff some time ago, but > internally, I was not really satisfied. > One point against something like

Re: [Kicad-developers] GitHub Plugin (my nemesis)

Just to be clear, currently, the plugin does not use GIT. It uses a proprietary GitHub Interface. I also checked out gitslave and similar stuff some time ago, but internally, I was not really satisfied. One point against something like this might be, that we actually make the work of the

Re: [Kicad-developers] GitHub Plugin (my nemesis)

My quarter-cent: Echoing Teger12506's comment, there may be some ways to keep them as separate repos in GIT and keep them manageable. I've seen gitslave work fairly well in situations like this: http://gitslave.sourceforge.net/ Continuing with using GIT sounds like the best option as opposed to

Re: [Kicad-developers] GitHub Plugin (my nemesis)

On 2017-09-22 03:44 AM, Oliver Walters wrote: that would certainly work but svn has the advantage of being able to pull selective directories from GitHub. As an FYI, you can use git to deal with an SVN repo using git-svn package. -- Cheers! Kevin. http://www.ve3syb.ca/ |"Nerds

Re: [Kicad-developers] GitHub Plugin (my nemesis)

True, I see the problem with everything in one repo with branches. Maybe it was not a good idea after all. 2017-09-22 11:13 GMT+02:00 Simon Küppers : > Good point, actually. > > > Am 22. September 2017 11:08:15 MESZ schrieb Miguel Angel Ajo Pelayo < >

Re: [Kicad-developers] GitHub Plugin (my nemesis)

Good point, actually. Am 22. September 2017 11:08:15 MESZ schrieb Miguel Angel Ajo Pelayo : >I believe it's better if each library type has a single directory on >the >top of the libraries repo, in a single branch. > >That would let you have branches like > >master >stable/4

Re: [Kicad-developers] GitHub Plugin (my nemesis)

I believe it's better if each library type has a single directory on the top of the libraries repo, in a single branch. That would let you have branches like master stable/4 stable/5 stable/6 later on, and point the specific versions of kicad to such branches, in a way that an old version of

Re: [Kicad-developers] GitHub Plugin (my nemesis)

Please don't use branches for that. Branches are to track separate development efforts or release cycles/stabilization. Using branches, while it's possible was not the intent when git was designed. If you do it that way, then you won't be able to use branches to track libraries in different

Re: [Kicad-developers] GitHub Plugin (my nemesis)

That actually sounds like a nice idea. Also the development of a single library would be local to the branch itself. Which could come in handy.. Then master could also hold Metadata (in a text file, but machine readable) of e.g. The address of the maintainer (email?) where changes are to be

Re: [Kicad-developers] GitHub Plugin (my nemesis)

I really like the idea of having one repo with all the .pretty folders in different branches. The master can have meta data about the branches. That also gives the ability to manage library downloads as you can download the branch as a zip. Using git for library management is ideally implemented

Re: [Kicad-developers] GitHub Plugin (my nemesis)

And by the way, this would be a feature that is completely new to the market (correct me if I'm wrong). Git integration into eda software. I only know of altium that has an svn interface and a proprietary vault. The features both of which could be (at some point) realized using git. Innovation

Re: [Kicad-developers] GitHub Plugin (my nemesis)

As said in this thread title, the plugin-idea is exactly what people are talking about here. There is a plugin interface within kicad for such stuff. Am 22. September 2017 10:32:21 MESZ schrieb Seppe Stas : >Honestly, I think KiCad should not manage library downloads by

Re: [Kicad-developers] GitHub Plugin (my nemesis)

Honestly, I think KiCad should not manage library downloads by itself. If this is a feature people want to use, it should be developed as a plugin. This way multiple plugins can exist that support different use-cases, like downloading plugins from git, a file server or SVN. What are the "ongoing

Re: [Kicad-developers] GitHub Plugin (my nemesis)

Hi, Am 22.09.2017 um 09:44 schrieb Oliver Walters: [...] svn has the advantage of being able to pull selective directories from GitHub. You could present the user with a list of which libraries they actually want to pull down So, just like JS (@tiger12506) I'm excited any time the git

Re: [Kicad-developers] GitHub Plugin (my nemesis)

My two cents (take with a grain of salt since I can't commit to it): https://libgit2.github.com/docs/guides/101-samples/ Having the plugin use the libgit2 library would be great, even people could get incremental updates via git, or even send patches/pull requests if they wanted... On Fri, Sep

Re: [Kicad-developers] GitHub Plugin (my nemesis)

Hi Oliver, IMHO, the library-download tool is the best choice here. I agree the live download is not a good idea in many cases, but I imagine there are people taking advantage of that (e.g. a centralized footprint repository in a small company). I think the main problem now, is we are relying

Re: [Kicad-developers] GitHub Plugin (my nemesis)

At this point, you can download a .zip or a .tar.gz from github of the libraries. The new library info will be put on the website too, so easiest option is just let the users download libraries direct from the KiCad website! If this is all that the git plugin is offering, I say that the

Re: [Kicad-developers] GitHub Plugin (my nemesis)

Simon, that would certainly work but svn has the advantage of being able to pull selective directories from GitHub. You could present the user with a list of which libraries they actually want to pull down Disadvantage is that (as you say) non github repos can't be used. Perhaps that's fine. On

Re: [Kicad-developers] GitHub Plugin (my nemesis)

Hi, It would be better to not rely on a GitHub specific SVN API. We can use git with --depth=1 for clones and updates (I added this to kicad-library-utils download_pretty_libs.py script recently). AFAIK, 3d modules take up the most space, so a shallow (depth=1) clone of (all) the symbol and

Re: [Kicad-developers] GitHub Plugin (my nemesis)

Sorry if I don't get it.. Why not just ask the user for a working directory and pull the libraries there using actual git? This has the obvious advantage, that anyone can use this not only with github but also with his or her own local repository.. Then maybe later add more functionality, such

Re: [Kicad-developers] GitHub Plugin (my nemesis)

I'm making more noise again. Have all options been explored? Sparse Checkout + clone depth = 1 https://stackoverflow.com/questions/180052/checkout-subdirectories-in-git Using different branches to differentiate content in git. Seems weird... but why not?

Re: [Kicad-developers] GitHub Plugin (my nemesis)

Jon, Using the SVN functionality of GitHub it's possible to do the following: a) Partial checkout (individual libraries as required) b) Checkout latest master c) Checkout tagged releases (e.g. 4.0.7) It would be "simple" to implement this using Python using the svn bindings. Would this be a

Re: [Kicad-developers] GitHub Plugin (my nemesis)

As a user, I always move to the edge of my seat when this conversation comes up. I sit there, waiting for awesome new features like in-program diff and pull requesting for kicad libraries, and then I inevitably sit back down because (IMHO) kicad wanted to use the github api and start wget vs.

Re: [Kicad-developers] GitHub Plugin (my nemesis)

I think it would make the most sense to do option (a), possibly also leaving open the possibility of changing the updates source location (for example, it's conceivable to have a mirror server at kicad-pcb.org that contains snapshots of the libraries that are compiled from the Git repo whenever

[Kicad-developers] GitHub Plugin (my nemesis)

Hi all, Ok, now that the website integration with the libraries is (pretty much) done, and the licensing issue seems to be sorted, there is one final puzzle piece to solve before I'm happy with the state of the libraries for a v5 release. *Goal: *Merge all footprint library repositories into a