The new SGP4 library comes with a Python wrapper in the same zip archive file (also Java, Matlab, and Visual Basic, and documentation for the C API), but it's not at all idiomatically Pythonic, since it sticks very closely to the underlying implementation in Fortran and C. I've written my own wrapper around their wrapper, to handle things like returning lists rather than forcing you to declare ctypes arrays and pass in their addresses as arguments, to make it more intuitive for Python programmers to call, but it's not actually necessary to add or change anything in order to use SGP4 to propagate TLEs.
However, this does not meet your stated desire, since it knows nothing of skyfield, astropy, or any other module outside the basic Python distribution, because that's the way my employer wanted it. It accomplishes many of the same tasks using the official US Space Force libraries for coordinate conversion, precession & nutation modeling, time manipulation, etc. which come with the SGP4 distribution. My employer also hasn't yet given me permission to share it, but I am trying to convince them.
Also, even if I did rewrite in my spare time and publish it, it still wouldn't allow you to make use of the new "extended perturbations" improvements in the latest SGP4, unless you have a way to get your hands on the new Type 4 TLEs, which as far as I know are not publicly distributed. If you do find a source for them, please let me know!
The releasable portion of the U.S. Space Force Standardized Astrodynamics Algorithm Library may be downloaded from https://www.space-track.org/documentation#/sgp4 after free registration and acceptance of license agreement. Among other things, that license says no one can distribute the libraries to anyone else. Every person who wants them must make a space-track.org account of their own, and download their own, separate copy. You may freely distribute code which calls the libraries, but the libraries themselves must always come only from space-track.
The entire distribution, when unzipped, occupies 72 MB. This breaks down as follows:
- 4 MB Documents (.doc and .docx)
- 56 MB Lib
- 21 MB Linux 32-bit (.so)
- 20 MB Linux 64-bit (.so)
- 8 MB Windows 32-bit (.dll and .lib)
- 8 MB Windows 64-bit (.dll and .lib)
- 10 MB SampleCode
- 480 kB API documentation (.txt)
- 860 kB C
- 360 kB C#
- 320 kB Fortran
- 4600 kB Java (not a typo, it really is ten times the size of most others)
- 310 kB Julia
- 300 kB Matlab
- 1500 kB Python
- 360 kB Unit Tests (C# for MS Visual Studio)
- 780 kB Visual Basic
- 2 MB Verify (sample inputs and the outputs they should produce)
If you are very short of space, you can delete some of the extra libraries that are distributed but you won't be able to use because you won't have the inputs they need. For example, you could save 316 kiB from Linux64 if you delete libvcm.so, which is only needed to parse a file format you only get if you are doing official business of the U.S. Government.
So far, I have found no need for different wrappers on Windows and Linux, apart from the standard Python use of the os module to access the file system, such as os.path.join() rather than '/'.join().
