Another comment: the whole kicad expression is really tough to override. For instance, changing src does nothing since it's set to base. But base is in a let expression so can't be changed.

So it seems like the easiest way to use a git version or local path for src is to copy the whole expression, edit it to use the local repo, and then call that build expression.

I'm closing this as I'm not convinced my PR is a good idea and my comment without an associated patch isn't super useful. I do think there are problems with this package expression that should be addressed, but I'll hold off until I have some actual changes that others can review. Of course if you disagree feel free to reopen.

huh, not sure why i wasn't added as a reviewer

i did not consider ease of use of mixed components
i suspect it's rare enough that the "do it manually" option is adequate
i think my approach would be to change versions.nix if i wanted to change the library used
#82634 moves libraries and base out of the let block, which may allow such a thing from nix

i overhauled most of the kicad package a while ago but didn't receive much feedback
the previous approach was to create links which left the env var way of overwriting those paths open
this unfortunately tied the compiled source to specific libraries (meaning i had to recompile every time i wanted to try another wrapping related change)
this remains the approach for the i18n because that can't be supplied as an env var

@matthuszagh if you end up reviewing the package, please tag me, or try me on IRC

@evils I'm reopening this, and will fix merge conflicts. I'd like to get your input. I know you mentioned that you would override versions.nix. However, because versions is imported in a let block, I don't see a way to overlay this. Maybe I'm missing something easy though? Additionally, and more importantly in my mind, this still suffers from the library files not being writable.

Adding path arguments, as this PR does, provides a simple way to get either behavior (yours by default). Do you see any significant downside to it?

you mentioned that you would override versions.nix. However, because versions is imported in a let block, I don't see a way to overlay this.

i meant my approach if i wanted to mix and match libraries would be to edit the versions.nix file in my nixpkgs checkout (i hope there is a nix native way to change either the content or which file is used, but haven't considered that)
or if i had a local library i wanted to use, add it to kicad via the GUI

this still suffers from the library files not being writable

as long as the library files are distributed by nix, that's always going to be the case?
i don't think the library files are supposed to be writable, my approach if i want to change a something in them is to make add a modified version as a project specific library, which accompanies the project and is writable

Do you see any significant downside to it?

if it fulfills the needs of a user that is not met by the current package, it's probably worth a bit of 'clutter'

Thanks for the feedback @evils!

as long as the library files are distributed by nix, that's always going to be the case?

Agreed, and that makes sense. The nice thing about this PR is kicad doesn't need the actual files, it just needs the path string so doing this doesn't create any purity issues. For instance, I'm using this with flakes and it works fine.

if it fulfills the needs of a user that is not met by the current package, it's probably worth a bit of 'clutter'

Yes, that it does.

Rebased for this PR.

@doronbehar if you don't mind, it would be great to get your feedback on this PR too.

@doronbehar changes done. Let me know.

@matthuszagh, this is all wrong, because makeWrapper supports:

So I'd suggest to make this PR do nothing besides switching the --set arguments to --set-default. Please explain your use case in the commit message.

@doronbehar change done.

Thanks for your contribution.