Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Moved winetricks to submodule #125

Merged
merged 3 commits into from
Sep 19, 2024
Merged
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension


Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
3 changes: 3 additions & 0 deletions .github/workflows/ci.yml
Original file line number Diff line number Diff line change
Expand Up @@ -14,6 +14,9 @@ jobs:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
with:
submodules: recursive
fetch-depth: 0
- name: Set up Python
uses: actions/setup-python@v5
with:
Expand Down
3 changes: 3 additions & 0 deletions .gitmodules
Original file line number Diff line number Diff line change
Expand Up @@ -7,3 +7,6 @@
[submodule "subprojects/xutils-dev"]
path = subprojects/xutils-dev
url = https://salsa.debian.org/xorg-team/app/xutils-dev.git
[submodule "subprojects/winetricks"]
path = subprojects/winetricks
url = https://github.com/Winetricks/winetricks.git
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Have to check in about this -- whether we want to always use the latest winetricks. I think we do though. However, I think it would be better if we fork winetricks instead. That way, we wouldn't be fully dependent on them when things break, especially when they are relatively trivial to fix (e.g., digest mismatches).

Once we create our own fork, we'd also have to update the Makefile so it will be added to the dist directory.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Winetricks is moving pretty slow and the releases are getting quite stale. We want to use the latest, I think.

The submodules are actually fixed on a specific commit though, so we don't need to use the latest. There's really no difference from the current solution.


I'm working on a reimplementation of Winetricks in Python. I can't give an ETA at the moment, but I have some groundwork and I'm working on an importer that converts the verbs into a maintainable file format.

Winetricks is huge though... and slow. It has a lot of functionality, so it will take some time to implement all of it.

I hope to finish work on it, but don't hold your breath. I'm not sure if I'm motivated enough to finish this little side project.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We can actually override verbs for small fixes by adding them to the local verbs. So we don't need to fork.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm working on a reimplementation of Winetricks in Python. I can't give an ETA at the moment, but I have some groundwork and I'm working on an importer that converts the verbs into a maintainable file format.

Winetricks is huge though... and slow. It has a lot of functionality, so it will take some time to implement all of it.

I hope to finish work on it, but don't hold your breath. I'm not sure if I'm motivated enough to finish this little side project.

This is great. Yes, I have been deliberating about a winetricks rewrite for a bit and had kinda planned for this, actually. Like the rewrite would be tailored to Proton, only containing the most useful verbs and metadata of them would be separated from the main program to separate files (e.g., toml, json, etc.). And while I imagine a rewrite in Python would speed up its runtime execution, be simpler, and better designed, I believe only part of its execution would be sped up unless we do not create subprocesses to wine binaries like the original script or perhaps if the registration of DLLs is possible to do in a thread-safe manner (which I haven't really explored yet).

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think it would be modules that can be imported with a CLI that imports the modules as well. Since the verbs would be in individual files, it doesn't really matter if there are only the most useful verbs or all of them. I will implement the most used functions of the verbs first, which should port most of the verbs pretty fast.

I believe only part of its execution would be sped up unless we do not create subprocesses to wine binaries like the original script or perhaps if the registration of DLLs is possible to do in a thread-safe manner (which I haven't really explored yet).

This is an issue, but I think some verbs are overkill.. like installing a complete software suite for having a dll.. but to refactor and test those verbs, we would need way more manpower. Not realistic atm.. but registering dlls or changing the registry might be viable.

1 change: 1 addition & 0 deletions ruff.toml
Original file line number Diff line number Diff line change
Expand Up @@ -27,6 +27,7 @@ exclude = [
"site-packages",
"venv",
"protonfixes_test.py",
"subprojects",
]

# Same as Black.
Expand Down
1 change: 1 addition & 0 deletions subprojects/winetricks
Submodule winetricks added at 72b934
Loading