I would guess that even though it’s using buildPythonPackage, it’s not using the same buildPythonPackage, since the underlying python derivations are different. You probably can’t mix and match packages from python scopes built on different interpreter derivations.
I could’ve sworn I was advised by others in the community that this was how to use older versions of packages when newer versions had bugs. How can I use newer versions, then? By overriding the source?
Regarding coverage, I was trying to follow rich's makefile test. Am I missing anything by omitting the coverage report?
And for the overlays, how do I access other packages, for, say, additional build inputs? I’d assume using the new and old keywords / arguments, but I split up the functions for easier modularity, so I don’t really have access to them most of the time.
You can try but you can also run into problems. I think it could work that you apply toPythonModule to the package but you might also run into the next problem.
The default toPythonModule does not allow me to overridePythonAttrs after the fact, such as to temporarily disable tests for a specific build; I had to modify it in an overlay to include the functions. Should that be raised as an issue on the nix / nixos report?
Yes, see the python language docs on how to do that.
I am aware of this, but the main reason I want to use the newer versions themselves is so that I don’t have to replicate any new build dependencies, ignored tests, check inputs, etc. Should I just grab anything I might need from from the new version, and override the source manually from there?
And got it; thanks for the confirmation on the overlay!
Also, quick note: when I override the src, both the old version and the new version seem to be being built (as shown in the build logs, where you can see both versions’ paths), and the old version is hitting the errors I’m trying to avoid with the new version.
Wait, no, sorry; my fault. Modularization can get extremely confusing at times.