Add crates overrides #298
Add crates overrides #298
Conversation
A bit of history. The workspace shell started off as a quick solution to get overrides to express some of their side effects within the user's development shell. Because it didn't work closely with the actual mechanisms of mkShell, the chosen mechanism, from overrides to dev shell, was use of propagated inputs. This and some cargo culting had resulted in overrides mimicking other overrides, lots of use of propagatedNativeBuildInputs. First, workspace shell's overhaul is given the actual package set instead of the noBuild set that is used when running tests. (the tests themselves may need similar overhaul). The new shell has one simple job: Make everything required to build every crate, except rust crates themselves, expressed in environment and available from the store. This has to be done for the entire rust crate DAG. Second, once the workspace shell could correctly express dependencies and shell hooks etc without the abuse of propagated inputs, the overrides themselves could be made much more sensible, much more consistent with the rest of Nix. substractLists works fine for derivation filtering The issue that lead to using attrSets was using the wrong crate outputs to filter on. After that was fixed, it was no longer necessary to construct attrSets by keys. If complexity of a dependency set (n^2 because of lib.unique) becomes too high, the attrSet based implementation should become favored again. This won't really show up to users for n < 1000 where n is the immediate dependencies of crates that are not crates themselves. Apple frameworks must be propagated? Missing a setupHook?
Just submodules
If an explicit workspace is configured in a crate's manifest, it will brake when we move that manifest out of the way for indpendent crate building.
This only works with nightly toolchains. Likely doesn't work at all whenever the flag should affect dependencies, which cargo cannot access / decide within the sandbox
|
Sure, let's sort alphabetically. I would take a look at if your dependencies will work as just build inputs. It's not usually the case that they need to propagate. pkg-config from nixpkgs will usually be transitively included because of a crate depending on the pkg-config crate. This is an example where a dependency must be propagated. For normal libraries, it's usually fine to leave them in Apple frameworks for some reason still require propagation, perhaps a linking style issue. You can continue committing on this branch and I will cherry pick over your commits and handle manual conflict. Attribution is retained. |
|
I force pushed the file you are working on in #292 |
litchipi
force-pushed
the
add_crates_overrides
branch
from
c402244
to
cdc88fe
Compare
These crates are necessary for building a Tauri application Signed-off-by: Litchi Pi <[email protected]>
litchipi
force-pushed
the
add_crates_overrides
branch
from
cdc88fe
to
a3586a9
Compare
|
I tried to have the minimal amount of propagated inputs, and this setup should now work ! |
|
LGTM. I'll handle any nits if any come up. Will be in unstable and 0.12 (doesn't exist yet) after close |
Context: I'm trying to build a Tauri application using Nix.
All these crates requires an overlay, and I thought it would be preferable to add them directly there.
I copied the format used in the file, and it works well like this, feel free to edit it as you want.
Does this file require to be sorted alphabetically ?