Request for consideration of NixOS support

[3demax]

This is a follow-up on the idea of building this library against different version of c libraries .

Disclaimer: I'm not a maintainer of the NixOS pkg in question. I'm just a passerby trying to give back to the projects I like.
Which is to say I am really grateful the effort that was put into this library so far. Thank you!

The "default way"

I suppose the current build/usage environment centers around setuptools+pip/pypi infrastructure. Which is a fair and reasonable, because it is likely the most popular setup.
However I wonder if you'd be interested in collaborating to open it up a little bit to another paradigm?

The "nix way"

The way you can think about how nix package manager (of NixOS) works is by having sort of a virtualenv for the whole system. So you can declare that your package depends on libc, OpenGL, etc. This works particularly well for python packages that depend on C libraries, like raylib.

But as you can imagine, the paradigm here is a little different. Since I don't uses pip install (but still use setuptools), I don't really need to build against the versions provided in this repo, I just point to "system-level" packages. Particularly, to "glfw", "raygui" and "physac". Which, arguably, better follows the idea of "shared libraries".

For illustration's sake, you can imagine that there is a nix-requirements.txt that says

libglfw==3.4
libphysac==1.1
...etc...

Current setup

All it takes to add this support is to point pkg-config to proper package names, like in this PR: 3demax#1
This gives pkg-config a hint to search for headers in the right place:

$ pkg-config --variable=includedir raylib
/nix/store/d97xvhykr21lqwqvlmc6f7477cwprym0-raylib-5.5/include

$ ls -la /nix/store/d97xvhykr21lqwqvlmc6f7477cwprym0-raylib-5.5/include
total 468
dr-xr-xr-x 2 root root   4096 Dec 31  1969 .
dr-xr-xr-x 5 root root   4096 Dec 31  1969 ..
-r--r--r-- 1 root root 130625 Dec 31  1969 raylib.h
-r--r--r-- 1 root root  82281 Dec 31  1969 raymath.h
-r--r--r-- 1 root root 250204 Dec 31  1969 rlgl.h

The way they do this currently is by having a patching get_the_include_path and it's calls, as in this patch (nevermind it's a bit redundant, I'd like to get rid of it anyway).
Which you might say is fair, "maintainers gotta do what they gotta do", but I think it is kinda ugly.

I feel like adding support for both of these paradigms is possible. l just need some time to think of a list of valid approaches.
Maybe parametrize build.py? Or using a separate setup.py.
Would appreciate you thoughts on this.

[electronstudio]

Your PR https://github.com/3demax/raylib-python-cffi/pull/1/files looks OK (but I haven’t tried it to see if it breaks any other builds.)

Also worth noting that some people don’t want to use pkg-config at all - CommaAI are doing this master...commaai:raylib-python-cffi:master
so would be good to have a way to override paths

[electronstudio]

PR isn't going to work on non NixOS systems because they don't have separate packages for raygui, glfw and physac. So would need to have fallback if packages don't exist.

I think probably NixOS is doing this wrong by allowing raylib-python-cffi to build against the system packages for raygui, glfw and physac. I designed the build so it was possible to use different versions by installing them at system level but this isn't something that majority of users will ever want to do. For the official binary builds we just take the bundled versions and copy them to /usr/local so the build finds them. So I think probably NixOS should be using our bundled versions.

[electronstudio]

I think best thing to do is allow the file paths to be specified by environment variables and only fallback to using pkg-config if they aren't specified. Then Nixos can build against whatever they like without patching.

[electronstudio]

#172