search

electronstudio / raylib-python-cffi

Python CFFI bindings for Raylib
http://electronstudio.github.io/raylib-python-cffi
Eclipse Public License 2.0
142 stars 29 forks source link

Lingering references to 3.5.0 and 301 #33

Closed adamlwgriffiths closed 3 years ago

adamlwgriffiths commented 3 years ago

Looks like 3.7.0 changes were merged with commit 124f0c77a98c1d8395ed443b37cd0e165ea9965e. But there are a number of references to 3.5 still in the repo:

https://github.com/electronstudio/raylib-python-cffi/blob/master/raylib/dynamic/__init__.py#L9-L10

(Note: this one mentions 3.5.0 and 301)

https://github.com/electronstudio/raylib-python-cffi/blame/master/README.md#L75

electronstudio commented 3 years ago

This is an issue with Raylib. They failed to update the file names to 3.7. So when you install Raylib 3.7 you get files with names like /usr/local/lib/libraylib.so.3.5.0.

The file name in the README could be updated but it's never going to exactly match what the end user has anyway, because different systems will produce different file names. it's just an example.

electronstudio commented 3 years ago

Since Raylib itself doesn't remember to update these names, and since it's annoying for us to remember, maybe we should just remove the version numbers?

Currently on my system I have raylib 3.7 installed and the file names are: libraylib.so, libraylib.so.351, libraylib.so.3.5.0

The first two are sym links. So with your patch it will search for:

['libraylib.so.3.7.0','libraylib.so.3', 'libraylib.so']

The first two will fail and then it will succeed with the third. So maybe we just remove the first two?

adamlwgriffiths commented 3 years ago

I think we could. I just wasn't sure I could speak for all distros.

As you say, the 3.7.0 tag has the incorrect version specified and the resulting binary is listed as 3.5.0. In my Nix package I incorporated this commit which fixes this. This was merged as part of this PR. So Nix has the proper filename for raylib 3.7.0.

lrwxrwxrwx 1 root root      16 Jan  1  1970 libraylib.so -> libraylib.so.370
-r-xr-xr-x 1 root root 1534000 Jan  1  1970 libraylib.so.3.7.0
lrwxrwxrwx 1 root root      18 Jan  1  1970 libraylib.so.370 -> libraylib.so.3.7.0

Perhaps libraylib.so + env var is enough, as for this to work I need to either:

Prior to my PR, the code was looking for the packaged raylib .so in the hardcoded "raylib/dynamic" directory. With my PR this is configurable, although using LD_LIBRARY_PATH might be a better option (ie load the .so without a path prefix).

FYI, I addressed these issues in this PR: https://github.com/electronstudio/raylib-python-cffi/pull/34

electronstudio commented 3 years ago

Raylib really needs a stable branch.

I'm happy to merge your PR I just wasn't sure if you want to change anything else.

Previously I was shipping one single wheel file that contained static libraries and dynamic libraries (in "raylib/dynamic") for all platforms. However this isn't how Pypi is supposed to work - there is supposed to be one wheel per platform. Then if it can't find one for your platform is automatically builds it from source.

So for the 3.7 release I switched to multiple wheels, each containing the static libs for one platform and no dynamic libs at all.

I think ideally the dynamic version should be a totally separate library, because it doesn't require building and does work on any platform that user supplies libs for. However I haven't done this because I don't find the dynamic version to be as good so I don't use it myself or really want to encourage other people to use it.

adamlwgriffiths commented 3 years ago

Lets move the conversation over to the PR