I don't know if gstreamer applications (like totem) can automatically use the pipewire plugins when available. If this is the case, then we should probably make an GST_PLUGINS_SYSTEM_PATH_1_0 environment variable instead.

If these are just extra GStreamer elements, an app would have to explicitly incorporate them into its pipeline. And then adding them to each app through wrapper would be better. If they include some extension point that introduces new codecs (not sure how that works but both are looked up using that env var), it might make sense to install them globally, though personally I am not a fan of global environment variables.

After a bit of research, I found that gstreamer can definitely pick up new sinks and sources automatically. See the documentation for autoaudiosink:

It does so by scanning the registry for all elements that have "Sink" and "Audio" in the class field of their element information, and also have a non-zero autoplugging rank.

However this does not apply to pipewiresink (yet?) because it has the Sink/Video class, and its autopluggin rank is 0.

I'm not looking forward to add pipewire.lib as a buildInput to all gstreamer-based applications once pipewiresink becomes autopluggable though..

In retrospect, I'm not sure if this PR is really that useful after all. If you want to use gst-launch-1.0 you need gst_all_1.gst-plugins-{base,good,bad,ugly} anyhow and then you can just add pipewire.lib to the list.