RFC: call for release v2.0.0

[miurahr]

Now v2.0.0 development reaches v2.0.0rc1 release candidate.
There is no further blocker issue, I'd like to propose it as general release v2.0.0.

If anyone have pending issues for v2.0.0 development, please tell me to make a head up.

[pzhlkj6612]

Hi. Thanks for your hard work!

I have a question. There are some old sections in the current README.rst:

• Install
• Usage(as in v1.2.x)
• Installing tool and utility (Experimental)
• Target directory
• Command examples

Will these sections be removed before releasing v2.0.0? The documentation has been already running on https://aqtinstall.readthedocs.io/ , including versions prior to v2.0.0.

[ddalcino]

That's a good idea for a PR. It would be pretty easy to copy the relevant sections from the new docs.

[pzhlkj6612]

Fixed by #377.

[ddalcino]

I have two potential items:

Consider removing the addon. prefix in module names for Qt 6

For the 'Qt Charts' module, aqt will only install the module if you call it qtcharts for Qt 5.15 and below, but you have to call it addons.qtcharts for Qt 6.1 and above. I don't think that this is the wrong behavior for aqt; addons.qtcharts is what it's called in the repo, and it's also what aqt list-qt calls it when it prints the list of available modules.

However, this behavior is not what people expect from aqt. I think that people expect to be able to call the module qtcharts no matter what version of Qt you're trying to install. There are plenty of attempts to install Qt 6.2 with qtcharts here: https://github.com/jurplel/install-qt-action/actions. PR #335 was an attempt to allow this usage to work. If we don't change this behavior, I'm sure that we will see more people filing issues and PRs intended to "fix" aqt when it's not actually broken.

If the guiding principle of aqt's development is "don't surprise users" or "don't break other people's code", then I think that aqt should be changed to allow people to run aqt install 6.2.0 <host> <target> -m qtcharts, instead of aqt install 6.2.0 <host> <target> -m addons.qtcharts. #335 does not do this properly, and it would take a lot of extra code to get it to work. However, I think that if we are going to make this change, we should do it before 2.0 is released, since it is a breaking change to the interface.

Edit: This suggestion was implemented and merged in #368

Fail if any packages are not installed correctly

I think it would be really useful to users if aqt would actually print an error message and return 1 when it fails to install a module. It looks like #334 was an attempt to make this change, but it relies on the Settings object to figure this out, which is the wrong approach. I think that aqt should keep track of what it has and has not installed correctly, and use this information to decide whether or not a failure has occurred.

This isn't really a breaking change to the interface, but I would at least like to talk about it before 2.0 is released.

[miurahr]

Thank you for comments.

Consider removing the addon. prefix in module names for Qt 6

Yes, it is an item we should deal with, and, IMHO, it requires hard work in several weeks, or month, and big code changes.
We have already taken several months to make aqt stable with the new long waiting features, such as list-* and install-tool subcommands.

I wander whether it is better choice to ask users waiting for the further improvement.

"don't surprise users" or "don't break other people's code",

Yes it is important principle and I agree it.

[miurahr]

Fail if any packages are not installed correctly

I agree it should be.

[ddalcino]

Yes, it is an item we should deal with, and, IMHO, it requires hard work in several weeks, or month, and big code changes.
We have already taken several months to make aqt stable with the new long waiting features, such as list-* and install-tool subcommands.

You are right. I understand if you want to push 2.0 out now; we have been working on it for a long time. I think that while the addons. thing is a breaking change, it would probably be ok to push it to the next minor release.

I have a preliminary fix for this at #368, but I think it needs to be tested a little better before it can be merged.