Execute without installation

[GoogleCodeExporter]

Running pgreloaded from checkout allows testing alpha's without installing, 
running `hg bisect` to search for bugs and enables to play with multiple 
versions without messing with virtualenvs.

Original issue reported on code.google.com by techtonik@gmail.com on 16 Jul 2012 at 7:19

[GoogleCodeExporter]

The modifications seems easy - just renaming `lib` directory to `pygame2`.

Original comment by techtonik@gmail.com on 16 Jul 2012 at 7:20

[GoogleCodeExporter]

The directory layout was chosen to avoid conflicts at run-time with installed 
versions. It will not be changed.

Original comment by marcusvonappen@googlemail.com on 16 Jul 2012 at 7:48

• Changed state: WontFix
• Added labels: Type-Enhancement, OpSys-All
• Removed labels: Type-Defect

[GoogleCodeExporter]

I guess you've meant the opposite. When you execute `make runtest` - which 
version is tested - the one you're working one, the one installed or the one in 
the virtualenv? Which Python installation is used to execute it - is it PyPy, 
Python2 or Python3? Explicit is better than implicit.

Original comment by techtonik@gmail.com on 16 Jul 2012 at 7:50

[GoogleCodeExporter]

make runtest executes the version installed for the specific `python` 
installation, depending on the make and shell environment. One should be aware 
of what python version in which environment will execute at that specific time, 
if issuing this command.

Original comment by marcusvonappen@googlemail.com on 16 Jul 2012 at 8:37

[GoogleCodeExporter]

When you execute the code from the source, do you want the version from the 
source executed, or the one installed in your current environment?

Original comment by techtonik@gmail.com on 16 Jul 2012 at 8:39

[GoogleCodeExporter]

Executing the test code from within the source code archive will cause it to 
use the relative test code, but the installed pygame2 packages. This allows one 
to create tests quickly against a typical installation environment instead of 
the (possibly unclean) source folders.

For a typical end-user test, please take a look at the make testall2 target, 
which uses the pygame2.test module which aims to perform a clean installation 
test.

Original comment by marcusvonappen@googlemail.com on 16 Jul 2012 at 9:14

[GoogleCodeExporter]

In my practice writing tests to installed package is a rarely used scenario. 
When working with the source I prefer to run stuff against this source. Your 
workflow makes it impossible to just press F5 in your IDE to launch the test - 
you need to create launcher that does 'make install/run test'. You can't add 
package to PYTHONPATH, because the 'lib' name is not the name of the package. 
You also need to run this as root or else you get:

creating /usr/local/lib/python2.7/dist-packages/pygame2
error: could not create '/usr/local/lib/python2.7/dist-packages/pygame2': 
Permission denied

In this case your system will be polluted with (possibly unclean) source folder 
potentially breaking other programs that depend on pgreloaded. And Python 
doesn't even provide a way to clean up the stuff. You need to know how your 
package is installed to erase the files manually.

You should also be aware that executing `python test/util/runtests.py` will 
only add test/util to PYTHONPATH, not the root of the package, so the conflict 
you're trying to avoid occurs only when your scripts are located directly in 
the checkout root. As pgreloaded doesn't have too much garbage in the checkout 
root - there is nothing to be afraid of. pgreloaded cleaned up the pygame mess 
in the source root, so it is logical to make pgreloaded further consistent with 
best practices incorporated into pyglet, pyprocessing, nodebox and other Python 
packages over the years.

Original comment by techtonik@gmail.com on 17 Jul 2012 at 3:47