+1 makes things much all-packages.nix much nicer to look at ... any objections to not merge this?

(triage) would we like to get this rebased and merged?

@pikajude ping. could you rebase this on current master?

I think, he won't. maybe somebody else wants to do this? @peti do you use mac os x?

👍 for the cleanup/idea, but we'll have beware of name clashes. Note that Darwin seems short on maintainers currently and it's likely this won't be among the top priorities (but that depends on the particular people).

@Mic92, I don't have access to a Darwin machine, I'm afraid; I won't be able to help much with this PR.

@peti sorry I thought you did.

@copumpkin, @vbgl, @acowley, @grahamc, could you help to rebase this?

To ground things like name collision concerns a bit, here is the list of identifiers that would be brought into scope.

I would like to see some simplification to the mechanism by which darwin-specific dependencies are pulled in:

• the current need to inherit from multiple places is a nuisance
• frameworks are quite highly coupled, resulting in there being several ways to write a list of dependencies such that everything needed is included (e.g. you can just depend on Cocoa to pull in everything it depends on)

I think I'd be more inclined to have a simple (maybe default scope) way of bringing in a large subset of the system frameworks, libobjc, and xpc rather than everything included in the above-linked list. Would that kind of approach appeal to anyone else? It might not be possible to agree on a list of essential frameworks (straw man: Cocoa, AVFoundation, AGL and their transitive dependencies), but I'd be up for trying to do so.

@grahamc @LnL7 any thoughts on this?

@acowley you were worried about too much stuff being brought into scope? Should this be discarded for a different approach or should we solve the conflicts an move ahead somehow ?

I added darwin.callPackage when doing some cleanup of the darwin expression, that could be used to enable this behaviour where desired.

@LnL7 would that become the stdenv.callPackage on darwin? I don’t think (but I could be wrong) moving the callPackage call into a conditional would be too popular as a wide-ranging change across nixpkgs. I also still don’t understand how to make callPackage customization compositional, so I am reluctant to lean on it.

I’d be happy if we moved frameworks directly under darwin as a minor concession to usability.

@gilligan I certainly don’t want to be an obstructionist to this effort, so if you have an idea of how something like the GLUT framework can avoid conflicts with some other GLUT package, I’d be on board.

@acowley No it's opt-in, currently most expressions explicitly pass the darwin dependencies they need. With darwin.callPackage those packages will be in the default scope, but it has the caveat that it might shadow toplevel packages.

{
  libusb1 = callPackage ../development/libraries/libusb1 {
    inherit (darwin) libobjc;
    inherit (darwin.apple_sdk.frameworks) IOKit;
  };

  libusb1 = darwin.callPackage ../development/libraries/libusb1 {};
}

@wizeman @orivej another example of an accidentally closed issue

@pikajude I'm still on the fence about this one but could be swayed if you feel strongly about it. I definitely don't like having to pass all the frameworks around explicitly, but am also fearful of some very easy confusion with some of the Apple libraries, including things like ICU vs. icu

Anyone wants to pick up this work or can we close it due to inactivity?