Add quodlibet-2.5: GTK+ based music player written in Python

[coroa]

No description provided.

[vcunat]

@coroa: for the purpose of applications, they find them through their private env vars set in the wrapper. There's probably no reason to have the plugins in (user) env, but I suppose you can install them by nix-env as anything else.

[coroa]

@vcuncat : @Phreedom : sorry, but that doesn't quite answer my question. to go into further detail: i understood from phreedom and the corresponding discussion on the mailinglist (thread:env vars glue), that there are basically 2 approaches for multimedia apps based on gstreamer:

the first one would be to just relie on the env vars being set correctly.

the second one, which this pull request originally proposed is to wrap the multimedia app to set up the env vars so they point to specific versions of the multimedia plugins. this is not a bad approach per se. but a better implementation of this approach would be a nix function that takes a nix expression, which implements the unwrapped application from approach one, and wraps it automatically to return a nix expression for <application>_wrapped. like this it is easier for the user to decide if he wants to take care of the multimedia plugins on his own and it is also easier then to override the wrapping parameters.

i don't feel like being able to properly take care of approach 2 at my current level. so i want to implement just approach 1, the no-wrapper-approach.

basically this means stripping the postBuild = ''' ... wrapProgram ...''' lines from my commit. the only thing which i don't like then, is that, if a nix user then installs quodlibet by calling nix-env -i quodlibet, quodlibet will only work properly if the user has either also called nix-env -i gst-plugins-{base,good,ugly} or even added these to his configuration.nix's systemPackages. isn't it somehow possible, that the quodlibet expression requires gst-plugins-* to be installed and available in the environment?

sorry for the rather long introduction to my probably simple question. (hint: "no" is a perfectly valid, but unfortunate answer).

[Phreedom]

There's nothing wrong with your pull request as-is even if you don't have time/experience/desire to figure out the plugin mess. I simply ran out of time to do nixos things for a few days. I also understand that you don't want approach #1(many people don't, even though this is the way other apps work right now).
@viric: I have another twist on the wrapper idea: what if we wrap by default apps installed via nix-env and don't wrap apps installed by nixos, by overriding some global config when importing nixpkgs in nixos?

[Phreedom]

Another good idea: make a my-env based script which sets all the env vars in question similar to the way nixos does. Maybe all these things together will finally fix this env hell.

[vcunat]

@Phreedom: I already thought about this style of wrapping (the wrapping info would probably be in nix-support folder), it could be even for all dynamic libs. There's a disadvantage that you couldn't directly run applications that weren't in an env... you would have to create some temporary env or something.

I was thinking of this for normal dynamic linking, because minor library updates would cause no binary change in the package (as in other distros). Only the rebuild would check that there's really no change and the wrapper would switch to the new library versions... that could save much space on disk for normal maintenance/bugfix updates, without breaking purity -- the old wrappers would just still link to old libs as before. However, we would need the intensional model with hash rewriting (see the thesis, chapter 6 http://nixos.org/~eelco/pubs/phd-thesis.pdf ).

Anyway, I would be in favor of intensional store for more reasons. @edolstra: do you think this could be the future of nix?

[vcunat]

Now I got to it. It works fine, and this way of handling plugins is preferred by me anyway. The double wrapping isn't a very nice thing, but it gets the work done well.

[vcunat]

Thanks!