Pygame with changed location of SDL

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
12 messages Options
Reply | Threaded
Open this post in threaded view
|

Pygame with changed location of SDL

kodicoding
Hello Dear Community,

I am trying to bring pygame to a system which sadly has a ro system partition. To be precise its Libreelec which is a just enough OS for the Homecinema Software Kodi. So due to it's limitations you can't install anything into /usr/ or similir folders. But you can Install addons, which also are able to contain binaries and libraries. So id like to know if there is a way to change, where pygame is looking for the SDL libraries.

Thank you very much

Reply | Threaded
Open this post in threaded view
|

Re: Pygame with changed location of SDL

Thomas Kluyver
I think it should respect standard mechanisms like the LD_LIBRARY_PATH environment variable.

There are also ways to edit the binary to modify where it looks for libraries: we do this in order to bundle libraries like SDL into the Linux wheel packages. But I don't think this kind of trick should be necessary for what you describe.

On 19 November 2017 at 16:11, <[hidden email]> wrote:
Hello Dear Community,

I am trying to bring pygame to a system which sadly has a ro system partition. To be precise its Libreelec which is a just enough OS for the Homecinema Software Kodi. So due to it's limitations you can't install anything into /usr/ or similir folders. But you can Install addons, which also are able to contain binaries and libraries. So id like to know if there is a way to change, where pygame is looking for the SDL libraries.

Thank you very much


Reply | Threaded
Open this post in threaded view
|

pygame.image.load - PyCharm inspection warning

Irv Kalb
I have two questions about pygame.image.load.  Here's the first:

I use IDLE when I teach classes.  But when I am trying to develop something for myself, I use PyCharm Community Edition.  There are many things I like about PyCharm and one of them is the analysis of errors that is available in the right edge of the editor window (inside the scroll bar area).  It gives me a very nice "inspection" check on errors and warnings in my code.  While I can ignore many of the warnings, I like to get rid of as many as possible.  One of the warning messages is annoying and I don't understand it.

I have built a minimal text case to demonstrate the problem:

import pygame

testImage = pygame.image.load('images/testImage.png')
print('testImage is:', testImage)


With just this program in an edit window, I get a warning message on the line with pygame.image.load call.  The warning message says:

   Cannot find reference 'load' in 'image.py' more ...

If I click on the more, it tells me: 
    
     This inspection detects names that should resolve but don't.  Due to dynamic dispatch and duck typing, this is possible in a limited but useful number of cases.  Top-level and class-level items are supported better than instance items.


If I run the program, it correctly outputs:

('testImage is:', <Surface(5x9x32 SW)>)

I have used pygame.image.load for years without any problems.  My code is working fine.

My question is, is there anything that can be done to eliminate this warning message?

Thanks,

Irv
Reply | Threaded
Open this post in threaded view
|

Building paths & pygame.image.load documentation

Irv Kalb
In reply to this post by Thomas Kluyver
Here's my second question about pygame.image.load.  Actually it's a question about specifying paths in pygame.

In my classes, I talk about the concept of a path for loading images, sounds, etc.  I suggest that students create an "images" folder and if needed, a "sounds" folder in their project folder.   I explain the difference between absolute and relative paths, and I point out the reasons why relative paths are generally easier to use for loading such assets.

I then explain that with this type of structure, that building a path to each asset is a matter of specifying the folder name (and optional subfolder name, etc.) and the file name.  I talk about how the different operating systems use different characters as the folder separator character.  But then I point out how Python solves this issue by allowing programmers to use the "/" character as the folder separator character - and how Python maps that character into the appropriate character for the operating system on which the program is running.  I give an example that I create my demo programs on a Mac, then bring them into class and run them on a Windows machine.  As long as I create paths like:

ball = pygame.image.load('images/ball.png')

This line will work on Macs and Windows (and I assume on Linux/Unix too). 

However, when I look at the documentation for pygame.image.load as an example, the documentation says:


You should use os.path.join() for compatibility.
eg. asurf = pygame.image.load(os.path.join('data', 'bla.png'))


My question is: Is there any reason to do it this way?  This requires bringing an additional package (the os package), an extra call (to os.path.join), and it would require much more of an explanation of what os.path.join does.  

I have also seen many other books/articles/other people's code where they do the same thing by building an absolute path on-the-fly.  This all seems like a great deal of overkill.

Any reason NOT to use:   

ball = pygame.image.load('images/ball.png')   

Irv




Reply | Threaded
Open this post in threaded view
|

Re: Building paths & pygame.image.load documentation

Ian Mallett-2
As far as I know, the os.path version does a string conversion to the platform-preferred way of specifying paths. So e.g. on Windows it replaces "/" with "\".

This is intended for compatibility with very Windows-focused apps that (deliberately?) don't understand "/". However, for the system-level application of loading files, "/" is a de-facto standard that all systems recognize.

The upshot is that either one will work. I personally use "/" because "\" was just not a good idea, and Windows ought to give up already--but it would be slightly more correct semantically to use the os.path conversion.

Regarding the extra dependency, os is built into every distro, so I wouldn't worry about it.

On Nov 25, 2017 12:01, "Irv Kalb" <[hidden email]> wrote:
Here's my second question about pygame.image.load.  Actually it's a question about specifying paths in pygame.

In my classes, I talk about the concept of a path for loading images, sounds, etc.  I suggest that students create an "images" folder and if needed, a "sounds" folder in their project folder.   I explain the difference between absolute and relative paths, and I point out the reasons why relative paths are generally easier to use for loading such assets.

I then explain that with this type of structure, that building a path to each asset is a matter of specifying the folder name (and optional subfolder name, etc.) and the file name.  I talk about how the different operating systems use different characters as the folder separator character.  But then I point out how Python solves this issue by allowing programmers to use the "/" character as the folder separator character - and how Python maps that character into the appropriate character for the operating system on which the program is running.  I give an example that I create my demo programs on a Mac, then bring them into class and run them on a Windows machine.  As long as I create paths like:

ball = pygame.image.load('images/ball.png')

This line will work on Macs and Windows (and I assume on Linux/Unix too). 

However, when I look at the documentation for pygame.image.load as an example, the documentation says:


You should use os.path.join() for compatibility.
eg. asurf = pygame.image.load(os.path.join('data', 'bla.png'))


My question is: Is there any reason to do it this way?  This requires bringing an additional package (the os package), an extra call (to os.path.join), and it would require much more of an explanation of what os.path.join does.  

I have also seen many other books/articles/other people's code where they do the same thing by building an absolute path on-the-fly.  This all seems like a great deal of overkill.

Any reason NOT to use:   

ball = pygame.image.load('images/ball.png')   

Irv




Reply | Threaded
Open this post in threaded view
|

Re: Building paths & pygame.image.load documentation

Irv Kalb
Thanks Ian.

I'm not worried about the os module being available.  I use pygame in classes that I teach, and it seems like its just one more thing for students  to understand and remember.  I teach mostly art students, very few computer science students.  I've used relative path like this:

pygame.image.load('images/ball.png')

for a long time and they had always worked for me.  Sounds like you have seen this too.  Unless I hear otherwise, I will use this approach as it is easier for students to comprehend.


As an aside ... I did development in another language/environment (Adobe Director/Lingo) for many many years.  Whenever we needed to specify a path, we had to build the full path including the folder delimiter character.  I started working in that environment in the days of Mac OS9.  At that time, the Mac folder separator character was the ":" colon character.  I didn't realize it but the character on a Mac is now the "/", same as the Unix character - probably changed when OS X came out.  I think either one will work on a Mac.  

When I started using Python, I thought it was very clever that I can use just the "/" character in Python, and Python seems to do whatever translation it needs to do to make the path work on the target system.  

Thanks,

Irv


On Nov 25, 2017, at 3:59 PM, Ian Mallett <[hidden email]> wrote:

As far as I know, the os.path version does a string conversion to the platform-preferred way of specifying paths. So e.g. on Windows it replaces "/" with "\".

This is intended for compatibility with very Windows-focused apps that (deliberately?) don't understand "/". However, for the system-level application of loading files, "/" is a de-facto standard that all systems recognize.

The upshot is that either one will work. I personally use "/" because "\" was just not a good idea, and Windows ought to give up already--but it would be slightly more correct semantically to use the os.path conversion.

Regarding the extra dependency, os is built into every distro, so I wouldn't worry about it.

On Nov 25, 2017 12:01, "Irv Kalb" <[hidden email]> wrote:
Here's my second question about pygame.image.load.  Actually it's a question about specifying paths in pygame.

In my classes, I talk about the concept of a path for loading images, sounds, etc.  I suggest that students create an "images" folder and if needed, a "sounds" folder in their project folder.   I explain the difference between absolute and relative paths, and I point out the reasons why relative paths are generally easier to use for loading such assets.

I then explain that with this type of structure, that building a path to each asset is a matter of specifying the folder name (and optional subfolder name, etc.) and the file name.  I talk about how the different operating systems use different characters as the folder separator character.  But then I point out how Python solves this issue by allowing programmers to use the "/" character as the folder separator character - and how Python maps that character into the appropriate character for the operating system on which the program is running.  I give an example that I create my demo programs on a Mac, then bring them into class and run them on a Windows machine.  As long as I create paths like:

ball = pygame.image.load('images/ball.png')

This line will work on Macs and Windows (and I assume on Linux/Unix too). 

However, when I look at the documentation for pygame.image.load as an example, the documentation says:


You should use os.path.join() for compatibility.
eg. asurf = pygame.image.load(os.path.join('data', 'bla.png'))


My question is: Is there any reason to do it this way?  This requires bringing an additional package (the os package), an extra call (to os.path.join), and it would require much more of an explanation of what os.path.join does.  

I have also seen many other books/articles/other people's code where they do the same thing by building an absolute path on-the-fly.  This all seems like a great deal of overkill.

Any reason NOT to use:   

ball = pygame.image.load('images/ball.png')   

Irv





Reply | Threaded
Open this post in threaded view
|

Re: Building paths & pygame.image.load documentation

Ian Mallett-2
On Nov 25, 2017 16:53, "Irv Kalb" <[hidden email]> wrote:
Thanks Ian.

I'm not worried about the os module being available.  I use pygame in classes that I teach, and it seems like its just one more thing for students  to understand and remember.  I teach mostly art students, very few computer science students.  I've used relative path like this:

pygame.image.load('images/ball.png')

for a long time and they had always worked for me.  Sounds like you have seen this too.  Unless I hear otherwise, I will use this approach as it is easier for students to comprehend.

Understood and agreed. I generally recommend relative, forward-slashed paths in every case, until and if some Windows utility decides to complain, which they usually don't anymore. The main holdout is the shell, which Windows continues, I assume just to be pissy. Fair enough; the UNIX equivalent, Bash, deliberately pretends to uncomprehend "\r".

I never use hardcoded absolute paths, since a relative path or a user-specified path is always (can't think of counterexample, and never ran into one) better.

As an aside ... I did development in another language/environment (Adobe Director/Lingo) for many many years.  Whenever we needed to specify a path, we had to build the full path including the folder delimiter character.  I started working in that environment in the days of Mac OS9.  At that time, the Mac folder separator character was the ":" colon character.  I didn't realize it but the character on a Mac is now the "/", same as the Unix character - probably changed when OS X came out.  I think either one will work on a Mac.

Hmm I didn't know this, never really viewing Macs as suitable for development. It's good it has converged to the forward-slash convention though.

When I started using Python, I thought it was very clever that I can use just the "/" character in Python, and Python seems to do whatever translation it needs to do to make the path work on the target system.

You'll see the same behavior in C, so either the standard library does the appropriate conversion before the ultimate syscall, or the syscall itself understands forward-slashes.

Thanks,

Irv

Ian
Reply | Threaded
Open this post in threaded view
|

Re: Building paths & pygame.image.load documentation

Greg Ewing
In reply to this post by Irv Kalb
Irv Kalb wrote:
> But then I point out how Python solves this issue by
> allowing programmers to use the "/" character as the folder separator
> character - and how Python maps that character into the appropriate
> character for the operating system on which the program is running.

This is WRONG. Python does no such thing. You are seriously
misleading your students by telling them this.

What's happening is that most Windows system functions
accept either forward or backward slashes as path separators.
So *most* of the time you can get away with using forward
slashes, but there are situations where that won't work.

> the documentation says:
>
> You should use |os.path.join()| for compatibility.
>
> My question is: Is there any reason to do it this way?

It's the only way that's guaranteed to work on all platforms
in all situations, so it's a good habit to teach and to get
into.

> Any reason NOT to use:  
>
> ball = pygame.image.load('images/ball.png')

If MacOSX, Linux and Windows are the only platforms the code
will be required to run on, this will probably work. But you
should point out to your students that you're taking a
shortcut by relying on this.

--
Greg
Reply | Threaded
Open this post in threaded view
|

Re: Building paths & pygame.image.load documentation

Sam Bull
In reply to this post by Ian Mallett-2
Also note that many parts of Python (since 3.6 I believe) now support Path-like
objects. Taking a quick look at the documentation (as I've not used them
before), it looks like your code would change to:

    from pathlib import Path
    pygame.image.load(Path('images/ball.png'))

If I run the path object through str(), I can see that on my system (which
creates a PosixPath) it outputs 'images/ball.png', while a WindowsPath will
output 'images\\ball.png'.

As long as it works in pygame, then that is probably the easier to understand
approach that still follows good practices and has maximum compatibility (as
long as you're not using older versions of Python).

On Sat, 2017-11-25 at 18:14 -0700, Ian Mallett wrote:

> On Nov 25, 2017 16:53, "Irv Kalb" <[hidden email]> wrote:
> Thanks Ian.
>
> I'm not worried about the os module being available.  I use pygame in classes
> that I teach, and it seems like its just one more thing for students  to
> understand and remember.  I teach mostly art students, very few computer
> science students.  I've used relative path like this:
>
> pygame.image.load('images/ball.png')
>
> for a long time and they had always worked for me.  Sounds like you have seen
> this too.  Unless I hear otherwise, I will use this approach as it is easier
> for students to comprehend.
>
> Understood and agreed. I generally recommend relative, forward-slashed paths
> in every case, until and if some Windows utility decides to complain, which
> they usually don't anymore. The main holdout is the shell, which Windows
> continues, I assume just to be pissy. Fair enough; the UNIX equivalent, Bash,
> deliberately pretends to uncomprehend "\r".
>
> I never use hardcoded absolute paths, since a relative path or a user-
> specified path is always (can't think of counterexample, and never ran into
> one) better.
>
> As an aside ... I did development in another language/environment (Adobe
> Director/Lingo) for many many years.  Whenever we needed to specify a path, we
> had to build the full path including the folder delimiter character.  I
> started working in that environment in the days of Mac OS9.  At that time, the
> Mac folder separator character was the ":" colon character.  I didn't realize
> it but the character on a Mac is now the "/", same as the Unix character -
> probably changed when OS X came out.  I think either one will work on a Mac.
>
> Hmm I didn't know this, never really viewing Macs as suitable for development.
> It's good it has converged to the forward-slash convention though.
>
> When I started using Python, I thought it was very clever that I can use just
> the "/" character in Python, and Python seems to do whatever translation it
> needs to do to make the path work on the target system.
>
> You'll see the same behavior in C, so either the standard library does the
> appropriate conversion before the ultimate syscall, or the syscall itself
> understands forward-slashes.
>
> Thanks,
>
> Irv
>
> Ian

signature.asc (188 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Building paths & pygame.image.load documentation

Greg Ewing
In reply to this post by Ian Mallett-2
Ian Mallett wrote:
> As far as I know, the os.path version does a string conversion to the
> platform-preferred way of specifying paths.

No, it doesn't -- that only happens if you use normpath():

 >>> os.path.join("abc/def", "ghi")
'abc/def\\ghi'
 >>> os.path.normpath('abc/def\\ghi')
'abc\\def\\ghi'

> "\" was just not a good idea, and Windows ought to give up already

It's not just Windows itself that would have to give it up,
there's application software that (incorrectly) believes "\"
to be the only true path separator on Windows.

--
Greg
Reply | Threaded
Open this post in threaded view
|

Re: Building paths & pygame.image.load documentation

Greg Ewing
In reply to this post by Irv Kalb
Irv Kalb wrote:
> I started working in that environment in the days of Mac
> OS9.  At that time, the Mac folder separator character was the ":" colon
> character.

Yes, in those days it was vitally necessary to use the os.path
functions for cross-platform code.

VMS is another example of a system which had wildly different
pathname syntax.

We're fortunate right now that the three major platforms have
partially-compatible pathnames. Whether that will continue
in the future is impossible to tell.

> I didn't realize it but the character on a Mac is now the
> "/", same as the Unix character - probably changed when OS X came out.

Yes, MacOSX is essentially Unix in many ways.

>  I think either one will work on a Mac.

If mean either "/" or ":", no, that's not true -- ":" is just
an ordinary filename character in MacOSX, same as Unix.

But, if you create a filename containng ":", the Finder displays
it as a "/" -- suggesting there's still something in there
somewhere that works with Classic MacOS style pathnames!

> When I started using Python, I thought it was very clever that I can use
> just the "/" character in Python, and Python seems to do whatever
> translation it needs to do to make the path work on the target system.

Which is an illusion caused by some degree of conversion in
the major platforms.

--
Greg
Reply | Threaded
Open this post in threaded view
|

Re: Building paths & pygame.image.load documentation

Greg Ewing
In reply to this post by Ian Mallett-2
Ian Mallett wrote:
> Hmm I didn't know this, never really viewing Macs as suitable for
> development.

Classic MacOS wasn't great for development, but MacOSX is
a flavour of Unix, so you get all the usual developer comforts.

--
Greg