# Frustrations about splicing

**URL:** https://discourse.nixos.org/t/frustrations-about-splicing/49607
**Category:** Nixpkgs Architecture
**Created:** [July 25, 2024, 4:43am UTC](https://discourse.nixos.org/t/frustrations-about-splicing/49607 "2024-07-25T04:43:43Z")
**Posts on this page:** 1
**Showing post:** 2

<div class="post-metadata">

### Author: ![SergeK](https://discourse.nixos.org/user_avatar/discourse.nixos.org/sergek/32/2972_2.png) [@SergeK](https://discourse.nixos.org/u/SergeK)
#### Post date: [July 25, 2024, 1:16pm UTC](https://discourse.nixos.org/t/frustrations-about-splicing/49607/2 "2024-07-25T13:16:27Z")

</div>

Yes I think it’s not splicing per se that is cursed, it’s the way we implement scopes and `callPackage`, which hinders both cross-compilation and situations like “there’s foobar in python3Packages but I need to ask for foobar from the top-level pkgs”. Then there’s also the general issue of expressing more complex graphs than `makeScope newScope` chains when working out of tree

I wish I could do a more explicit/fine-grained dependency injection, sort of like

```auto
# package.nix
{
  dependencies.wayland-scanner.name = "wayland";
  dependencies.wayland-scanner.offsets = "buildHost";
  dependencies.wayland-host.name = "wayland";
  dependencies.wayland-host.offsets = "hostTarget";
  recipe = { stdenv, wayland-scanner, wayland-host, ... }: ...
}

```

---

_[View the full topic](https://discourse.nixos.org/t/frustrations-about-splicing/49607)._