[Discussion] Improvement ideas about components

[Kinsteen]

For the first suggestion, it needs a lot of dev time imo. Either:

• we have a separate program that test this the same way Bottles does, which means more maintenance work as code is duplicated, and also stuff can break because the code is inherently not the same
• we create a new main that calls the appropriate functions of the Bottles backend, but it requires some work as a lot of classes won't be available as they're tied to the UI. Some overriding of functions that calls GTK/GLib would also be needed, at first glance.

I agree with the idea as it would definitely be very great, but it also feels like a ton of work... But this development is beneficial either way as that would essentially create unit/integration tests, which is always good (but annoying to do lol)

[koplo199]

@Kinsteen Oh, that indeed sounds... challenging haha :')
This is probably something that should be incrementally built over time, starting with the easiest checks to implement, in your opinion what a good first target would be?

Replacing the main and using the official functions looks like the way to go, as it should be a lot more easier to maintain than another standalone implementation, in addition to be less error prone: worst case scenario it pass the CI implementation, and not the official one shipped in Bottles, this is not something we want to happen

[Kinsteen]

Maybe using a Python testing framework could be nice, I never worked with that so I'm not even sure how it would work. Then testing function like download in the component manager could be nice as it would test the index downloading, parsing, the downloading of components, the folder structure etc... It should be doable, but I'm not sure if the maintainers want to implement this type of testing

[koplo199]

I agree, a testing framework should probably be used here in order to be as clean as possible. I did some research and it appears that pytest is often recommended, it also seems easy to use

[koplo199]

It seems dxvk-async isn't maintained anymore, a fork has been created (Sporif/dxvk-async#64 (comment)) which supports the latest dxvk version in addition of allowing the use of async and gpl at the same time. It probably needs more testing (nvidia gpus?), but may be worth adding as an unstable/experimental component.