Remove wheel from Repoitory

[0xbe7a]

Hello there!

I've noticed that the Python wheel file is currently stored directly in the Git repository. I'd like to kindly suggest that this file should be moved to GitHub's release artifacts instead. This change would help reduce the size of the source tarball, making it more efficient, especially for those of us packaging for systems like conda-forge.

Storing binary or generated files in the repository can significantly increase the clone and fetch times, and generally, it's a good practice to keep such files out of the codebase and manage them through releases and generate them using CI / GitHub Actions.

Thank you for your work on this project, and for considering this improvement!

Best regards, Bela

[Kalmat]

HI! Sorry I wasn't aware of such a good practice and the issues it may generate. You will see it done, count on it. I only have to understand how! If you can please give more details on how this can be done: "manage them through releases and generate them using CI / GitHub Actions". Otherwise, I will try to investigate.

Besides, I will do the same in all three repos I have: PyWinBox, PyMonCtl and PyWinCtl.

Thank you so much for your advice.

[0xbe7a]

Hi Kalmat,

https://packaging.python.org/en/latest/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows/

has an up-to-date guide on how to build and publish to PyPi and GitHub Releases

[Kalmat]

Thank you! The only problem is that, if I understood well, it seems to publish a new release in github and in PyPi (as well as in TestPyPI, that I don't know what it is) on every push, which is something I don't want to do. Sorry for my ignorance, but I am not skilled in github actions language. Is it acceptable in your case (and for other users) that I suppress the .whl files from the repo (stored in dist/ folder) and I add them to every new release as an additional binary file? I mean, using this option when creating a new release and dropping the .whl file as a separate item:

[0xbe7a]

Thank you! The only problem is that, if I understood well, it seems to publish a new release in github and in PyPi (as well as in TestPyPI, that I don't know what it is) on every push, which is something I don't want to do.

No: notice that if: startsWith(github.ref, 'refs/tags/') # only publish to PyPI on tag pushes inside the "publish-to-pypi" step? That makes sure, that this step only run after you added a git tag to an release. From an tag you can then also auto-generate your GitHub Release including a change-log. The GitHub Release step lists the PyPi as a dependeny, so it will also run when just publish a new tag.

I mean, using this option when creating a new release and dropping the .whl file as a separate item:

That would absolutely work, but I think that building a CI/CD workflow by yourself is probably a good exercise and learning opportunity for you and also a very relevant industry skill, if you want to try it 😄

Also, as a user of software, it often helps me because I can see the exact process of how a wheel was created which is helpful for debugging from time to time. It also saves you error-prone repetitive work through automation.

From a security perspective (which will probably become more relevant in the future), it also makes it easier for me / software to understand that it is an official artifact that was created transparently from a git state and does not contain additional (possibly malicious) changes / bugs.

[Kalmat]

Hi again! I have already removed the .whl file from all three repos, adding them to the latest release as a separate file. I will try to setup an automated github a CI/CD workflow, but this needs more understanding, work and test from my side.

Thank you again!