Add tarball and var outputs

[nicknovitski]

By moving the unarchiving of workspace dependencies "up" into the dist phase, it creates a useful output for SPAs and other "static" results.

Assuming that no one will try to install these outputs, I thought it would be safe and simpler to give the tarball a predictable name and not put a subdirectory in $var.

I'm leaving the installPhase overrideable just in case, though I can't think of when you'd need to override it.

[nicknovitski]

I should explicitly say: Fixes #66

[zimbatm]

Are there cases where all the outputs are necessary? It seems like it would create more work for nix that isn't necessarily being used.

[nicknovitski]

Well, let's quantify the work. This is the output of the yarn pack command for wetty:

yarn pack v1.8.0
warning Skipping preferred cache folder "/homeless-shelter/Library/Caches/Yarn" because it is not writable.
warning Selected the next writable cache folder in the list, will be "/private/tmp/nix-build-wetty-0.2.0.drv-0/.yarn-cache-30001".
success Wrote tarball to "/nix/store/0n4lggr525zg72xpj47ps0792yjmpbbj-wetty-0.2.0-tarball/package.tgz".
Done in 0.10s.

And this is the result of prepending time to the tar -xf line, also for wetty:

real    0m0.018s
user    0m0.005s
sys     0m0.010s

So on the order of a tenth of a second per-package. If that is problematic, I'd be happy to have doDist be overrideable.

As far as when all the outputs are necessary: there is no sub-command that just copies the contents which get placed in the archive by yarn pack, so it's sadly necessary to create the tarball in order to make the var output. But it's not necessary to keep it around afterwards. I only added a "tarballs" output since I had to make the file anyway, and I thought some people might be able to use it. But I have no objections to removing it.

So if doDist was overrideable and there was no "tarballs" output, would you have any objections?

[nicknovitski]

Some of my projects do have higher pack times, as high as 1.70 seconds.

[zimbatm]

I was wondering if there was a more elegant solution available. If only one of the outputs is ever needed at times them maybe another approach is possible. For example the user might select an outputType to be either a install, pack or unpacked-pack. That would effectively remote the need of the distPhase.

[nicknovitski]

You mean, as string argument to the function? What would make that interface more elegant than, for example, packageName, packageName.pack, and packageName.unpacked-pack? It seems like attributes make for a more confident interface for detecting errors faster, with less error-checking.

But, if I understand you, you are concerned about the time spent creating the other outputs? My experience so far is that the module install, build (for transpiled packages), and test phases greatly dominate package build time over the dist phase, but if you're sure, I don't mind getting rid of it. Rather than using a distPhase, I believe I could make passthru derivation(s) that were accessible with that kind of attribute interface. That was my first approach for making the tarballs, when I was first trying to support transpiled workspace dependencies, but I thought a distPhase was easier to understand. If I went back to that approach, would that answer your objections?

e: just in case I didn't understand you, if your main concern is just splitting the outputs, I definitely don't mind deleting that line and changing the distPhase to instead create $out/tarballs/${pname}.tgz and $out/var/${pname}/, to avoid conflicts.

[zimbatm]

Yes I meant an input type like:

mkYarnPackage {
  outputType = "dist";
}

But I get that unknown output types might have to be handled.

Anyways, let's go with your solution since you are doing all the work.

[zimbatm]

I'll merge this once it's rebased