When to drop support for platforms?

[CEXT-Dan]

Something to think about if it seems the package is getting too big.

[Shark-with-Blue-Shoes]

Can you clarify what platforms refers to?

[CEXT-Dan]

Currently, we have builds for AutoCAD 2021-2026. ZwCAD 2026 is on the horizon, probably GStar as well.
Anyway, I think the wheel from PyPi is 100mb, what is too big?

Considering chopping AutoCAD 2021-2023, I can leave the projects in place in case someone needs a build, they could just drop the binaries in place. I won’t do anything now, just asking

[CEXT-Dan]

Is there a way to clean the git history of .ARX files periodically?

[Shark-with-Blue-Shoes]

Git rebase is your best bet

[CEXT-Dan]

Thanks! I guess its recommended that a repo stay under 5GB, we are already pushing 3gb, I’m wondering if storing the history of ARX files is causing reason its growing fast

[gswifort]

I think the best solution is to remove the binaries from the repository. Instead, configure github to build them during release, before building the distribution and publishing to PyPI. I don't know how to do that, but I think it's possible.

[CEXT-Dan]

That would be ideal! Though I wouldn’t know where to begin. The build is enormous, spans multiple projects and SDKs, some of which are not open source.
I’m betting there’s some git commands to clear the history on certain files, as a short-term solution, I’m going to try and make a script to clear this

Another option is to move them to Git LFS
https://docs.github.com/en/repositories/working-with-files/managing-large-files/about-git-large-file-storage

Of course, this project will eventually stabilize on the C++ side

[CEXT-Dan]

I have no idea how this works, but I put the files in lfs

PS M:\Dev\Projects\PyRxGit> git lfs ls-files
959e8cc3fc * pyrx/PyRx24.0.arx
f465c836ac * pyrx/PyRx24.1.arx
7ff79992a9 * pyrx/PyRx24.2.arx
ddd766532e * pyrx/PyRx24.3.arx
0b7ade7465 * pyrx/PyRx25.0.arx
d0268109d8 * pyrx/PyRx25.1.arx
c831c962f7 * pyrx/PyRxG24.0.grx
b6eb9ca6b6 * pyrx/PyRxG25.0.grx
855c971e3c * pyrx/PyRxV24.0.brx
73700f34db * pyrx/PyRxV25.0.brx
fe05e3d776 * pyrx/PyRxZ24.0.zrx
a6e70d6f11 * pyrx/PyRxZ25.0.zrx
ae27cb8c5b * pyrx/PyRxZ26.0.zrx
678b9b14d0 * pyrx/RxLoader24.0.arx
1391f0a5df * pyrx/RxLoader24.1.arx
74b867545b * pyrx/RxLoader24.2.arx
e3f2ef3991 * pyrx/RxLoader24.3.arx
72030cd0ae * pyrx/RxLoader25.0.arx
7b445e9660 * pyrx/RxLoader25.1.arx
700896625d * pyrx/RxLoaderG24.0.grx
ac57b87ffa * pyrx/RxLoaderG25.0.grx
c96cbcd9eb * pyrx/RxLoaderV24.0.brx
3f010c98b1 * pyrx/RxLoaderV25.0.brx
3ca6b018ef * pyrx/RxLoaderZ24.0.zrx
663b5316dc * pyrx/RxLoaderZ25.0.zrx
4d28c5e545 * pyrx/RxLoaderZ26.0.zrx
PS M:\Dev\Projects\PyRxGit>

[gswifort]

Since these experiments the commit history keeps breaking down.
I reset my fork two days ago:

[CEXT-Dan]

DOH! Sorry about that. I tried to move the .ARX files to LFS, but quickly realized it was a bad idea. LFS has very limited free usage, I would have been only allowed three commits per month. There’s no compression, so, I put the binaries back into the repository.

The solution seems to be BFG Repo-Cleaner https://rtyley.github.io/bfg-repo-cleaner/ by removing the binaries, the repo size shrinks. I did some initial cleanup, I went back and deleted the huge html help files, stub files, and the history for the return types database.

I commit a lot, it’s a habit from my old job, basically every time I stop coding, I build and commit. But they were the ones paying the bills lol.
Anyway, going forward, I will need to do cleanup from time to time to avoid getting the email from GitHub. I will keep an eye on the size to determine the frequency, probably every few months

[CEXT-Dan]

CEXT-Dan/PyRx - 203 MB , down from 2.75 GB, the cleaning made a huge difference!