vanepp
commented
2 years ago OK, I have what appears to he a working script with a variety of improvements (including being able to deal with the breadboard svg also being the icon svg!) Below are the test results first from the original script then from my new script.
output from the original script:
$ obsolete.py core/Dual_VNH2SP30_Motor_Driver.fzp Dual_VNH2SP30_Motor_Driver
$ git status On branch develop Your branch is up to date with 'origin/develop'.
Changes to be committed:
(use "git restore --staged
$ vi core/Dual_VNH2SP30_Motor_Driver_44e6ab2_002.fzp
missing first line of file
KjellMorgenstern
I'm learning and documenting obsoleting, and as part of that have been poking at obsolete.py. Before I get too far I figured I should explain what I want to change and see if there is agreement or if I am overlooking something.
bug:
The dom returned by get_dom isn't the root, but rather return dom.documentElement and thus
s = new_fzp_dom.toxml("UTF-8", False)
doesn't emit the <?xml version='1.0' encoding='UTF-8'?> line (because the dom isn't the root) on the output fzp files (obsolete and core.) The above format also requires python 3.9 or later to add the standalone=no parameter (which most Fritzing fzps have.) Returning dom from get_dom and adding the .documentElement to all other dom references fixes that. I don't think that Fritzing cares, because UTF-8 is the default, but vim doesn't recognize the file as xml (and thus doesn't enable the xml checks.) I expect this shouldn't be controversial.
Next is an enhancement which may be more controversial. I'd like to remove the revision argument and replace it with the version in the fzp file with the new fzp and the svgs getting the current version plus 1. There are at least a couple of files in core parts that have a version 1.1 currently, so they would need to be updated to be 1 (so the version is an int.) If there is no version tag in the fzp file the code currently sets it to 2, and I think that 1 is a better choice (with the new fzp being 2.) In the case of a fzp with a version number the new version would be the current version + 1. I'm not sure if the revision argument is intended to allow something that I'm not aware of. I think (but haven't tested yet) that the current code will break if there is a version number in the fzp file. I think this code is going to break if there is a version tag in the fzp.
the last version.setAttribute I think will fail when the version in the else above has been replaced with the string for the version number as it will no longer be a Element but rather a string (the code above is in a new order than the current obsolete.py so as the deepcopy will get the new version element when there wasn't a version tag in the original fzp.) It also moves the version to right after the module at the top of the fzp to match the rest of the Fritizng fzps.
Next the new svg filenames will have the new version and the layerId appended so
svg/core/breadboard/Dual_VNH2SP30_Motor_Driver_2_55dde35_002.svg
would become
svg/core/breadboard/Dual_VNH2SP30_Motor_Driver_2_55dde35_2_breadboard.svg
where the _2 is the new version number (this part doesn't have a version tag) and the _breadboard is the layerId. The purpose of this is to make it easier to make fzpz files. The original version has the same file name for all the svgs and thus you can't copy them to a single directory to make a .fzpz file because they will overwrite each other. The new format tells you what you need to append (svg.breadboard. in this case) to make a fzpz compatible svg. The _002 in the original file name is the revision parameter and thus the question above if that is intended for something I''m not aware of. In the most common version in core parts (4) the new version would become 5.
Next I added code to search the bins/core.fzb file for the moduleId. I don't know what bins/core.fzb is for exactly (as all the core parts are not in it, but core/Dual_VNH2SP30_Motor_Driver.fzp is and if you don't replace it with the new moduleId you get the obsolete part in a core parts search. I expect we should possibly add all the core parts to this file as I don't see any reason why core/Dual_VNH2SP30_Motor_Driver.fzp is in it but most of the arduinos are not. It doesn't seem to be related to where in the parts bins the part appears. Nor does it appear to be parts that aren't in a bin (because the "arduino_Uno_Rev3(fix)" is there and it is in a bin as well!) There may be other files (that I haven't run across yet!) that also need updating. It is also unclear to me where you get the modelIndex field if you were adding a part (it doesn't apply in this case because I am assuming the current modelIndex will do, although that may not be true, it appears to work in the Dual_VNH2SP30_Motor_Driver.fzp case but may not in another case!)
Last I intend on adding a //obsolete// to the obsolete.fzp family attribute to match all the other obsoleted parts. I gather that replacedby is the only required field but this is easy enough to add and is useful in the case of bins/core.fzb to tell you you are looking at the wrong instance of the part.
Finally I don't think
"TODO: Support obsoleting a part without having a replacement. This could be useful for parts whic are not available anymore."
is a good idea. I suggested it in the forums and it was pointed out that even though the part is no longer available for sale, they are in people's possession of it, and it is probably still available on ebay et. al. used, so, as long as the part is correct, it is likely still useful for old sketches if nothing else!
Comments? Corrections?