You asked for it… But I’ll preface by acknowledging that this is mainly nitpicking on a useful tool, and I do honour the work it does and that went into it.
My main beef with this tools is, that it calls itself FritzingCheckPart and then merrily goes about changing my files. Hands off my files! If it was called FritzingFixPart or FritzingCleanupPart, okay. But for a checking tool, I expect it to not change anything unless explicitly instructed to do so.
Another thing that annoyed me, is its insistence on setting the referenceFile value to the current file name everywhere. I think that is unnecessary, or wrong. The reference file in SVGs is the filename of the SVG file that was imported into Parts Editor. That can be useful. And for the .fzp file, it is the name of the part that the new part was based on. This can be necessary, or annoying, but in any case I see no reason to unconditionally change it.
In progress. FritzingCheckPart.py will report only (and be part of the travisCI chain in parts submission which is why the no mods, because it won’t have write access.) To get there a few of the current false positives need to be corrected as it can’t false positive when that will block the part submission process. As well a bunch of new function (reading fzpz files directly, and being able to convert a .fzpz to repository format to submit parts) is planned but that is going slow as I am lousy at development. FritzingFixPart.py (a link to the same code with a different name) will do the current corrections usually with flags to disable them if you want for fixing up a new part.
Another thing that is likely to go. There is no documentation on what the reference file should be that I know of (like many other things) and no one left who knows what the original intent was, and a review of the code indicates Fritzing in most cases (except perhaps parts editor) doesn’t use it for anything.
I got the feeling that it has to do with part evolution. That is because I encountered some annoying behaviour of the Part Editor, when I started my part based on an existing one, and then went on editing the SVG and changing, e.g. connector0Pad to connector0Pin. Imported that into Part Editor for my part, and, lo and behold, the Part Editor simply kept the old connector0Pad. As it is in the part I based my part on.
That may also be caused by some caching, that I haven’t found yet. I even went so far as to uninstall Fritzing and delete the Fritzing directories left that I could find. Reinstalled, redid my new part, same result.
Maybe there was another caching directory left over that I hadn’t found yet. For a deeper analysis I would have to repeat the whole thing for a different part. But it felt like Fritzing likes to keep an inheritance chain when creating parts based on another one.
I think a link (hard or soft) should work on Windows although I use cygwin on Windows rather than native python. If not either a second copy of the code with a different name (assuming native python gets the program name in Argv[0]) or a command line flag will do the trick.
I find most of parts editor annoying (but to be fair it is not finished, it was still in progress when development died) and thus don’t use it. However that would match with parts editor being the only part of the code which uses the reference file (although the behaviour is annoying!)
Hm, I must say that other than these little quirks, I do quite like it. I don’t know why people find making parts so hard, but I haven’t used any other tool yet. I could imagine the schematic editor to be easier, but which other tool has a breadboard view? I think that is really helpful for beginners (like myself).
I have never managed to figure out how to set the terminalId position with the e/w/n/s settings, it sometimes generates pin numbers out of sequence (that one is a bug!), and it can’t do (at least yet) a variety of things that I sometimes do because it wasn’t finished when development stopped mostly. I find it easier to edit the underlying files, but that requires that you know what the xml does with takes a lot of time to learn.