By analyzing the blame information on this pull request, we identified @wkennington, @svanderburg and @flosse to be potential reviewers

Could we keep such files outside of nixpkgs repository? It's already really huge.

I'll take a closer look later, but @domenkozar which large files are you talking about?

@copumpkin nixpkgs is 450MB, let's make sure we don't add sourcecode to it. I'd just create a github repository and use fetchFromGithub to get sources.

You talking about the small shell scripts in this commit though? This
doesn't seem like a particularly bad offender.

I also share concerns about the repo size, but the giant autogenerated
package bundles seem like the bigger concern than one-off shell scripts. We
need to get import-from-derivation working properly and use it all over the
place!
On Mon, Jan 25, 2016 at 08:50 Domen Kožar notifications@github.com wrote:

@copumpkin https://github.com/copumpkin nixpkgs is 450MB, let's make
sure we don't add sourcecode to it. I'd just create a github repository and
use fetchFromGithub to get sources.

—
Reply to this email directly or view it on GitHub
#12604 (comment).

@copumpkin well this is how code starts to grow around :) I think all of those scrips should be moved, but we have to also make sure we don't add more.

@domenkozar sure, but I'd focus my shrinking efforts on the thing adding 99% of the new space automatically rather than the thing adding a kilobyte or two at a time, with human intervention. Humans are pretty bad at producing tons of data by hand. There's a cost to moving small scripts out of the repo (maintaining the hashes and so on), and when they're (small) core build scripts used by everything else, keeping them in the repo doesn't seem that bad to me. Or would you move cc-wrapper and the stdenv's setup.sh out of the repo too?

Sure, but expect me to comment on next commit that finds out this gluecode isn't enough :)

@copumpkin fixed

@domenkozar This derivation is 9.7KB in total and uses substituteAll pretty extensively, so my worry is that it wouldn't be as simple as it seems to break it out into its own package.

is this still relevant?

If we're going to merge this, following packages should be migrated to use nix-code as a dependency too:
Applications/audio/chuck/default.nix

• MacVim
• QT 5.6
• QT 5.7, currently in PR qt57: darwin compatibility #23602
• V8
• Xcodewrapper?
• Node Packages
• PhantomJS2
• Pinentry-mac

I think @matthewbauer's xcbuild and nixpkgs-based SDK for it cover most of the use cases for this, right?

@wizeman @orivej another example

@pikajude you still interested in pushing this?

Are there any updates on this pull request, please?