[Development] QLibraryInfo::path(): to deprecate or not to deprecate?

[Volker Hilsheimer]

> On 27 Jul 2026, at 13:21, Fabian Kosmale <fabian.kosmale at qt.io> wrote:
>>> On 27 Jul 2026, at 10:46, Volker Hilsheimer via Development <development at qt-project.org> wrote:
>>> 
>>>> On 26 Jul 2026, at 20:09, Thiago Macieira <thiago.macieira at intel.com> wrote:
>>>> 
>>>> In favour of QLibraryInfo::paths()
>>>> https://codereview.qt-project.org/c/qt/qtbase/+/744726
>>>> 
>>>> The correct thing to do is to deprecate, and force everyone who is using it to 
>>>> adjust to having more than one path. In a lot of cases, it's already used in a 
>>>> loop, so the fix is simple. In others, it's the right thing to do. And in the 
>>>> rest, it documents in the code that you're taking the first and ignoring the 
>>>> remainder, which is what path() does.
>>>> 
>>>> But it produces a lot of warnings in examples and tests.
>>>> 
>>>> Do we want this?
>>> 
>>> 
>>> https://codereview.qt-project.org/c/qt/qtbase/+/560001 introduced paths() with https://qt-project.atlassian.net/browse/QTBUG-124009 "Support a way to easily set import paths for QML engine & tooling” as the rationale.
>>> 
>>> Beyond QmlImportPaths, are there any other practical uses for respecting multiple entries?
>> 
>> 
>> Yes, see series of patches under this topic: https://codereview.qt-project.org/q/topic:%22qlibraryinfo%22
>> 
>> tl;dr, plugins and other artifacts covered by QLibraryInfo might live both in the installed Qt and the app bundle on Apple platforms during development. And when deployed (into a single app bundle) there might be several paths inside that bundle we want to look for plugins and other artifacts. 
>> 
>>> QLibraryInfo was originally designed to provide information about the Qt libraries, and having e.g. multiple locations of the Qt library translations, binary, or libraries doesn’t seem useful; but I might be missing something.
>> 
>> 
>> That was the original design, based on the premise that Qt lives in a prefix-installed system location. Today with reloactable Qt we’ve moved away from the original design, so it’s more of a “where should I look for things Qt needs”.
> 
> 
> Hi,
> 
> besides the Apple use case Tor Arne listed, I believe we have seen similar requirements for Harmony OS, and you also run into interesting issues with NixOS if I recall correctly (though the latter is at least not officially supported).
> Qt itself should definitely not use the singular form; I'm not quite sure how much usage the API sees in user applications.
> 
> In any case, if we deprecate the singe item API, we should however provide some more guidance than just "us paths".
> 
> Fabian



Ok; it then seems reasonable for the next step to be a cleaning up of in-tree code, see what we can learn from that (if anything; tests can perhaps get away with s/path()/paths().first()?), and only deprecate once we have a clean source tree ourselves and a good porting guideline.


Cheers,
Volker