resource path when using

[GoogleCodeExporter]

Found on debian wheezy, using the current release and the tip of pyglet using 
python 2.7.

Whenever I use profile or cProfile for some reason the relative path is changed 
to the system PYTHONPATH, this way pyglet is unable to find any files inside a 
resources directory provided on as a relative path.

Example:

Without profile,
1- The programmer provides '.' as the a resource path.
2- Pyglet translates '.' to '/home/myuser/fooapp/'

With profile,
1- The programmer provides '.' as the a resource path.
2- Pyglet translates '.' to '/usr/lib/pymodules/python2.7'

My suggestion is to include a recommendation on the "Specifying the resource 
path" telling users to use absolute paths.

Original issue reported on code.google.com by marcelos...@gmail.com on 1 Mar 2014 at 9:06

[GoogleCodeExporter]

Absolute paths are a bad idea and they're against the reason of resources:

http://pyglet.org/doc-current/programming_guide/resources.html#specifying-the-re
source-path

Can you provide information about "profile" and "cProfile"? If pyglet is not 
working properly with them I'm not sure if it is a pyglet bug.

Original comment by useboxnet on 2 Mar 2014 at 8:42

• Changed state: Blocked

[GoogleCodeExporter]

The problem manifests in cases like:
python -m cProfile -o /dev/null examples/programming_guide/image_viewer.py
python examples/programming_guide/image_viewer.py

The problem, however seems to be a bug with pyglet, in the function 
get_script_home from the module resource.py . Running the script below with and 
without cProfile should demonstrate the problem more clearly:
https://gist.github.com/marceloslacerda/9324582

This is a workaround I found:
https://gist.github.com/marceloslacerda/9324115

Original comment by marcelos...@gmail.com on 3 Mar 2014 at 1:12

[GoogleCodeExporter]

Understood! Indeed, there's a bug get_script_home(), in 
http://code.google.com/p/pyglet/source/browse/pyglet/resource.py#105

os.path.dirname only splits the provided path in components. If __file__ is 
used, there's no directory component and returns the empty string instead of 
the directory name.

The issue won't be visible if the script is executable (__file__ includes 
./FILE.py, so the script home will be ".").

I'm attaching a patch that should solve the problem. Can you give it a go?

Thanks for your report!

Original comment by useboxnet on 3 Mar 2014 at 1:35

• Changed state: Accepted
• Added labels: OpSys-All, Type-Defect
• Removed labels: Component-Docs, Type-Enhancement

Attachments:

• get_script_home.patch

[GoogleCodeExporter]

That does not fix the problem with cProfile. The following command still 
crashes:

python -m cProfile -o /dev/null examples/programming_guide/image_viewer.py

I have updated test_profiler with the information from your patch and the 
result is the same, using cProfile.

$ python -m cProfile -o /dev/null test_profile.py 
Printing absolute path for "."
/home/marcelo/workspace/marceloslacerda-pyglet
Printing get_script_home() output:
/usr/lib/python2.7
<module '__main__' from '/usr/lib/python2.7/cProfile.py'>

I think that the problem lies in using sys.modules['__main__']. That code is 
getting cProfile's module, instead of the module being profiled.

Original comment by marcelos...@gmail.com on 3 Mar 2014 at 2:58

[GoogleCodeExporter]

Well, if profile tempers with sys.modules I'm not sure if there's anything we 
can do. Using a full path when running the profiler is a good workaround, we 
can add a note in the documentation (your initial suggestion).

My patch fixes an issue though, so I think I'm still applying it.

Original comment by useboxnet on 3 Mar 2014 at 3:01

[GoogleCodeExporter]

I think profile doesn't even need to mess with sys.modules, what happens is 
that when I run python -m profile source.py, the python runtime runs profile 
and then profile executes source.py. Maybe I can fix profile by changing 
sys.modules in the profile source, but every other module(nose?) that is used 
to run source.py could cause the same problem.

Maybe adding a note is the easiest solution indeed :-)

Regarding your patch the previous "undocumented behavior" never affected me so 
I don't have any comments about it :-D

Original comment by marcelos...@gmail.com on 3 Mar 2014 at 3:39

[GoogleCodeExporter]

Yes, you're right. In fact it's not a bug and I would say it makes all the 
sense: get_script_home() is getting the script current directory, and that's 
different when running the script with the profiler.

So... agreed, a documentation not will be perfect :)

Thanks again for your report and help in this issue!

Original comment by useboxnet on 3 Mar 2014 at 5:22

[GoogleCodeExporter]

This issue was closed by revision cd79ee1faf54.

Original comment by useboxnet on 3 Mar 2014 at 6:34

• Changed state: Fixed