Test pyqt6

[m-kuhn]

Fixes #8
Fixes #9

[Neumann-A]

I think we need to delete something but the questions is what? Is something collecting a huge amount of logs/artifacts?

[Thomas1664]

I think we need to delete something but the questions is what? Is something collecting a huge amount of logs/artifacts?

I think the binary cache accumulated many entries from every PR run and source files are big as well.

Why do you only have 0,5 GB? I have 2 GB

[Neumann-A]

Why do you only have 0,5 GB? I have 2 GB

That seems to be the difference between Free and Pro. My personal account also has 2 GB but the organization has only 0,5 GB updating that costs 4 $ per user per month which is kind of strange unless the GB size also increases with the number of users. I wonder what "user" means here in organization context.

[m-kuhn]

I understood "public packages are free"
https://docs.github.com/en/billing/managing-billing-for-github-packages/about-billing-for-github-packages#about-billing-for-github-packages

[m-kuhn]

I enabled "public" packages now in https://github.com/organizations/open-vcpkg/settings/packages

[Neumann-A]

If the same packages for users apply to orgs the package stuff needs to be moved to somewhere else in the future. (E.g. there can only be one repo with vcpkg packages.) For example I have a private repo called my-vcpkg-packages which just handles the package stuff for all other repos due to that limitation

[m-kuhn]

If the same packages for users apply to orgs the package stuff needs to be moved to somewhere else in the future. (E.g. there can only be one repo with vcpkg packages.)

why?

[Neumann-A]

why?

Strange limitation of github if i remember correctly. You'll get strange errors if another repo tries to push github packages.

[m-kuhn]

why?

Strange limitation of github if i remember correctly. You'll get strange errors if another repo tries to push github packages.

It might be related to packages which are linked to a repository?
Reading about this, github suggests linking packages to a repository for ACL reasons. As I think we don't care and want everything public, this should be a non issue. If this is really the reason for the aforementioned limitation.

[m-kuhn]

Thanks for the add_dll_directory patch @Neumann-A c38149f

[Neumann-A]

Thanks for the add_dll_directory patch @Neumann-A c38149f

No problem more or less stolen from conda ;)

But be aware that embedded python needs a slightly better approach: The path const wchar_t python_path[] = L"\\tools\\python3"; can be \\tools\\<anything> in reality. Currently the patch only enables python3 itself to find the dlls. Stuff embedding python3 will still not be able to find the dlls without additional setup.

[m-kuhn]

But be aware that embedded python needs a slightly better approach: The path const wchar_t python_path[] = L"\\tools\\python3"; can be \\tools\\<anything> in reality. Currently the patch only enables python3 itself to find the dlls. Stuff embedding python3 will still not be able to find the dlls without additional setup.

Sounds like this should be done when loading the python dll (instead of executable) instead ideally?

Any last comments from your side before merging this?

[m-kuhn]

I'll merge later today unless there's an additional comment coming.
I'm quite happy with what's here. Even if it's not perfect yet, it's a good starting point for future improvements.