@peterhoeg, thanks for your PR! By analyzing the history of the files in this pull request, we identified @AndersonTorres, @rnhmjoj and @fpletz to be potential reviewers.

Typically waf is included in the distribution of the package that uses it. Is this package an exception?

mpv will try to download waf and then run it, which obviously doesn't work for us. The workaround introduced was to have nix pull it down instead, but as it is already available in nixpkgs, we might as well just use that.

mpv is a special case.
It doesn't embed waf inside sources as the other softwares usually do, but it actively downloads and checksum-verifies a particular waf version instead.
Also, waf's original developer doesn't think waf is made to be a system-wide application to be packaged, as we traditionaly do with Autotools or CMake. His point of view is waf is a build script, included as part of the source code bundle of every particular project which uses it [1].

I think our approach is currently the best we can do in due respect to the original developers - mpv and waf (and nixpkgs of course :))

1 - https://groups.google.com/forum/#!msg/waf-users/iK01e_K_WfQ/6n7AVlthYXIJ (see the last lines, the answer to 4th point)

So all other packages except for pflask embed waf.

So just because we can use the version in nixpkgs to build mpv doesn't mean it will continue to be the case of course. I'm still in favour of just using the version we have as it makes mpv simpler (not by much admittedly).

Any thoughts from the maintainer, @aszlig ?

@peterhoeg: I've just removed the attribute from buildInputs to prevent setup hooks being run, causing a build failure. Also, I'm not a maintainer of mpv, but from the URL @AndersonTorres provided above, I'd probably leave it as it is, because while it may save a few lines of Nix code, it might break mpv as soon as the waf package in <nixpkgs> is updated.

Guys, sorry about the maintainer confusion y'day. Let's leave as is to avoid problems.