[Development] Pending decisions on co-installation

[Chris Adams]

On Thu, Nov 1, 2012 at 10:56 AM, Thiago Macieira
<thiago.macieira at intel.com>wrote:

> On quinta-feira, 1 de novembro de 2012 10.01.11, Chris Adams wrote:
> > Regarding QML_IMPORT_PATH, I discussed this yesterday and this morning
> with
> > Martin Jones and Andrew den Exter, and a couple of things deserve
> > mentioning:
> > 1) through the versioning of imports (ie, the path lookup with
> major/minor
> > version appended to module name) a client can create a QML1
> > (QDeclarativeExtensionPlugin) module plugin and install it into, say,
> > "$QML_IMPORT_PATH/com/examplecompany/examplemodule1/" and then create a
> > QML2 (QQmlExtensionPlugin) module plugin and install it into
> > "$QML_IMPORT_PATH/com/examplecompany/examplemodule2/", and this will work
> > fine.
> >
> > That is, the QML_IMPORT_PATH need not be different (or set differently)
> > between applications using QML1 and QML2, so long as they import the
> > modules of the correct version (ie, for the version of QML against which
> > their application is written).
>
> That assumes that there is a different module name or version number, which
> isn't always the case. Qt Quick did decide to break source compatibility by
> requiring "import QtQuick 2", but the same does not follow for other
> imports.
>

I guess that's true.  But I would argue that any 3rd party module developer
who _doesn't_ bump the version of their newly updated module when they
rewrite it for a new major version of QML is probably doing their customers
a major disservice (since the API of every element they provide will most
likely have changed dramatically - even if they themselves didn't add or
remove any API - unless the types they provide merely extend QObject
instead of QDeclarativeItem / QQuickItem).

But you are right.  The versioning of the module and the versioning of the
language are separate, and in the case that they aren't using the QtQuick
primitives, for example, the API offered by types provided by a 3rd party
module may remain unchanged, and thus the version should remain unchanged
also.  I withdraw my argument for my previous stance ;-)


>
> Note that there already was a separate import path for Qt Quick 1 by
> appending
> "QtQuick1" to the paths found in QML_IMPORT_PATH. And it is used by some
> code
> that we install ourselves, like Qt.labs.folderlistmodel.
>
> $ cat imports/Qt/labs/folderlistmodel/qmldir
> plugin qmlfolderlistmodelplugin
>
> $ cat qml/Qt/labs/folderlistmodel/qmldir
> module Qt.labs.folderlistmodel
> plugin qmlfolderlistmodelplugin
> typeinfo plugins.qmltypes
>

Unfortunately, folderlistmodel was never properly maintained.  I don't know
if we bumped the version of it correctly, for example, which is why it
looks like it hasn't been installed into a folderlistmodel2 directory.  I'm
not sure what you mean by the "appending QtQuick1 to the paths found in
QML_IMPORT_PATH" -- you mean, in our code at plugin loading time in
importdatabase or something?  I don't remember that code too well, but
arbitrarily changing the import path supplied by the user seems like a bad
idea (eg, we can't guarantee that the client has the module they want,
installed into QML_IMPORT_PATH/qtquick1 instead of just QML_IMPORT_PATH
etc).  But I've probably misunderstood what you meant here, can you clarify?

In any case, given your previous point (that is, that the version of
modules needn't be bumped, necessarily, just because the version of QML
changed, if their API remains unchanged) I now am forced to agree with your
point that the import paths do need to be separate, for this
3rd-party-module-versioning reason.


>
>
> > So, I'm not sure that QML_IMPORT_PATH needs to be versioned, so long as
> > QML's imports versioning system works as expected in future versions.
> > I'm not sure that we need to have a qt5/imports dir for QML1 plugins and
> a
> > separate qt5/qml dir for QML2 plugins, since coexisting qq1/qq2 plugins
> > worked previously according to versioning, with the same import path.
>
> No, they didn't. They already had different import paths before I started
> doing
> anything. All I did was change the paths searched and the environment
> variables that supply the paths.
>

> > A
> > problem might occur if you set QML_IMPORT_PATH to point to a qt4 (QML1)
> > import path, and then run a qt5 QML1 application - it'll be trying to
> load
> > QML1 plugins built against qt4, which will fail.
>
> Indeed, but hopefully the Qt plugin system will simply refuse to load the
> plugins, avoiding a crash. The QML plugins *are* Qt plugins, loaded via
> QPluginLoader, aren't they?
>

Yes, we use QPluginLoader to load plugins in
qdeclarativeimport.cpp/qqmlimport.cpp.


>
> This is the same situation with QT_PLUGIN_PATH, which is unversioned.
> However,
> the plugin magic is incompatible between Qt 4 and 5, so we can keep the
> same
> environment variable, which contains both sets of plugin paths. Qt 4 will
> not
> load Qt 5 plugins and Qt 5 will not load Qt 4 plugins.
>

Right.


>
> > Anyway, the long and short of it is -- these variables / configure
> options
> > are all developer-facing, so to be honest, we don't think it's a huge
> issue
> > to change them if we want to, or leave them (and document the differences
> > if required) if that is simpler or less confusing.
>
> All of them except for QML_IMPORT_PATH. That can be expected to be set on a
> production system, like some other variables that modify Qt's behaviour
> post-
> installation:
>
>         QT_PLUGIN_PATH
>         QT_QPA_PLATFORM_PLUGIN_PATH
>         QT_QPA_PLATFORM
>         QT_MESSAGE_PATTERN
>

You're right.
Ok, all in all, I think having separate import install paths and separate
envvars to define the import path basedir at runtime is the best solution
after all.

Cheers,
Chris.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/development/attachments/20121101/053b0c76/attachment.html>