Platform-Agnostic Testing

[MagikEh]

We should consider porting our testing setup/run/checking/teardown scripts from bash-based, to python-based so they work cross-platform (looking at you apt-get).

• Figure out how to move/find/install things on each platform via python super libraries (import *)
• Robot-framework? -Reid
• Cheese windows by using git bash? -James
  • Git is already a requirement of the project
  • It's built on mingw..

[petersilva]

um... there is no portable way to install things... you may be mad at apt, but rpm, winget, etc... all have portability issues, if not with the tools themselves, then with the packaging environment around them (which dependencies are in the repositories in the various ecosystems.) I can't even get one set of code working between redhat 8 and redhat 9. While we aren't testing packaging systems, we do need to test that the packages that we produce are correct.

As for replacing bash with python... the stuff we are doing with bash is all platform specific, how do you call winget from python? you're going to end up with if statements switching between apt & rpm & winget (& portage on mac) anyways. having the if statement in the code is probably more complicated than having per platform scripts.

I guess we could do the config file building in python, and get the file locations using Sarracenia itself... dunno.

Yes python developers can (should?) just use pip, which is relatively portable, but I've had all manner of issues with people not having compilation environments and so not being able to install dependencies where python packaging requires building c-stubs. This is mostly a windows thing, but also a huge pita on redhat 8.

And then there is setup.py... this was the blessed way to create packages (wheels) using python, but is now deprecated and should be replaced in modern distros, except the modern blessed ways don't work on the old OS and python versions ( https://github.com/MetPX/sarracenia/issues/740 )

A large subset of users want to use it as an OS tool, so would expect it to be "just there" on the system, which means using OS packages.

distilling that into requirements of the testing regime:

• It tests python and C packages regardless of how they are installed, packages (RPM, deb, wheel, whatever, or just stuff in the PATH)

• It works across a wide variety of OS versions.

• It works across a wide variety of python versions.

"Temporal" portability... sigh...