setuptools / easy_install / egg support

[GoogleCodeExporter]

Would you be interested in a patch that based setup.py on setuptools, so it 
could be installed as an 
egg?

Original issue reported on code.google.com by snick...@gmail.com on 28 Oct 2008 at 7:59

[GoogleCodeExporter]

That would be great. Thanks for the support!

Original comment by sir...@gmail.com on 29 Oct 2008 at 2:44

• Added labels: Type-Enhancement
• Removed labels: Type-Defect

[GoogleCodeExporter]

would be great

Original comment by santagada on 29 Oct 2008 at 7:38

• Changed state: Accepted

[GoogleCodeExporter]

This requires some fairly major hacking into the build, so I wanted to get 
feedback as I've worked on this 
today.

1) To support easy_install requires all building/setup to be done from within 
python (no separate "Makefile" 
step). I've just instructed python to compile all .cpp files, and it seems to 
work fine. Thoughts?

2) My setup.py is considerably simpler than the existing one, which could be 
good or bad. My understanding 
is that a well-structured setup.py should be nearly identical on Windows, OS/X 
and Linux, but I can't test 
under Windows. I've tried the other two, and it works fine. In some ways, not 
doing the Makefile as a separate 
step simplifies things because there's no outside-libs that need to be linked 
in, its all just another object file 
compiled as part of building the extension.

Original comment by snick...@gmail.com on 29 Oct 2008 at 11:31

[GoogleCodeExporter]

Oh, also, is there a reason the module is "Box2D2" instead of "Box2D"? It seems 
like its more "python-y" in 
general to just use the name, and then easy_install Box2D does what's expected. 
For backward-compat (is that 
an issue yet?), it would be easy enough to create a Box2D2 __init__.py that 
throws a deprecation warning and 
then imports Box2D.... or honestly at this point it'd be easy enough for 
library users to update to Box2D when 
they upgrade.

Original comment by snick...@gmail.com on 29 Oct 2008 at 11:34

[GoogleCodeExporter]

No separate Makefile would be okay, assuming it works. I had nothing but trouble
getting setup.py working with the lack of documentation (and experience) for it 
and
struggled with Extension() for a while.

Perhaps my hacks for win32 were because I used it improperly. We'll see what 
happens,
I guess. 

The reason for Box2D2 was that originally I had a Box2D v1.4.3 version (Box2D) 
and
then worked on the new version 2.0, and so the library became Box2D2. I 
regretted the
poor naming scheme after realizing it might cause confusion in the end. I think 
the
deprecation warning sounds great.

Original comment by sir...@gmail.com on 29 Oct 2008 at 11:55

[GoogleCodeExporter]

If you could try a (not finished) setup.py patch and advise me how it works 
with MinGW before I do all the 
finishing work, that would be really useful. I've got a distutils compiled 
Box2D working on OS/X and Linux.

Does it seem reasonable to put setup.py in the top-level directory?

Original comment by snick...@gmail.com on 30 Oct 2008 at 1:25

[GoogleCodeExporter]

Oh, also, is float vs. fixed compilation important for pybox2d? It seems like 
if you're running python you're 
probably on a standard fixed-point processor, but perhaps that is not a good 
assumption???

Original comment by snick...@gmail.com on 30 Oct 2008 at 1:26

[GoogleCodeExporter]

Sure, I'd be glad to test it out. setup.py will eventually go in the top level
directory (see issue 13).

Fixed-point support was in there because I wanted to try it out on NDSPython 
(Python
for the Nintendo DS). When that didn't work after a few tries, it just stayed 
where
it was. It can be safely ignored.

Original comment by sir...@gmail.com on 30 Oct 2008 at 2:33

[GoogleCodeExporter]

I just did an svn diff, which didn't seem to remove old files, but you can try 
this out. It doesn't do Box2D2 compat 
yet, but that's easy. Lemme know how this works on Windows!

Try just plain "python setup.py build" first, and if that doesn't work, please 
try "python setup.py build -cmingw"

thanks!

Original comment by snick...@gmail.com on 30 Oct 2008 at 2:50

Attachments:

• pybox2d_patch

[GoogleCodeExporter]

It'll be great if it's as easy as your setup.py indicates. 

A few things:
1. How should the testbed be dealt with? I'd like those files accessible 
through the
egg, but currently they aren't copied. I'm not sure what's standard.

2. setup.py clean still doesn't work properly. It doesn't get rid of the 'build'
directly completely or the Box2D.py that somehow gets generated in the base 
directory.

3. Wasn't working on Windows, unfortunately. With an additional "-I." it's now
compiling. However, the problem that I had run into before (which I semi-forgot 
about
with -c mingw32) is this:

kne@KNE-PC /d/dev/new_setup
$ setup.py install
running install
running build
running build_py
running build_ext
error: Python was built with Visual Studio 2003;
extensions must be built with a compiler than can generate compatible binaries.
Visual Studio 2003 was not found on this system. If you have Cygwin installed,
you can try compiling with MingW32, by passing "-c mingw32" to setup.py.

kne@home /d/dev/new_setup
$ setup.py install -c mingw32
usage: setup.py [global_opts] cmd1 [cmd1_opts] [cmd2 [cmd2_opts] ...]
   or: setup.py --help [cmd1 cmd2 ...]
   or: setup.py --help-commands
   or: setup.py cmd --help

error: invalid command 'mingw32'

kne@home /d/dev/new_setup 
$

'build' works fine with -c, but 'install' doesn't.

As such, it's still required for win32 users to modify their distutils.cfg. Even
doing so, the files are installed like this:
\Python25\Lib\site-packages\Box2D-2.0.2b0-py2.5.egg-info (fine)
\Python25\Lib\site-packages\_Box2D.pyd (why is this here?)
\Python25\Lib\site-packages\Box2D.py   (why is this here?)

All of them should be in a directory site-packages\Box2D.

I might've had something similar to this during my first few attempts at the
setup.py, but not being able to get things where I wanted it, I eventually 
modified
it into the current abomination. 

See the new branch here:
 http://code.google.com/p/pybox2d/source/browse/branches/new_setup/
New setup.py here:
 http://code.google.com/p/pybox2d/source/browse/branches/new_setup/setup.py

Original comment by sir...@gmail.com on 30 Oct 2008 at 9:34

• Added labels: Priority-Low
• Removed labels: Priority-Medium

[GoogleCodeExporter]

hey sirkne, I hadn't worked much on the installed form yet, but its pretty 
simple to modify... i wanted to make 
sure the general approach to compilation was at least somewhat compatible with 
windows, it sounds like the 
gnarly bits are actually in installation though. I'll try to get windows/mingw 
working in a vmware image so I 
can debug this.

    packages = ['Box2D'],
    package_dir = {'Box2D': 'Box2D'},

These are (AFAICT) the recommended way to do package installations, and should 
put things in sub-dirs. The 

    py_modules = ['Box2D2'],

line installs a "reverse compatibility" Box2D2 module (not done yet, but its 
basically an __init__.py with a 
warning and then "from Box2D import *"

For binary extensions, for whatever reason, its recommended to use _Package for 
the binary file, and then 
include Package that imports the binary file. distutils has trouble dealing 
with SWIG if this assumption isn't 
met, and you need a number of workarounds.

But they SHOULD both be installed in a Box2D sub-dir, its interesting if that's 
not happening on windows. Is 
.pyd the extension for binary python modules on windows? If it is, what I'd 
expect, and you can tell me if this 
is what you want, is....

\Python25\Lib\site-packages\Box2D\Box2D-whatever.egg-info
\Python25\Lib\site-packages\Box2D\Box2D\__init__.py
\Python25\Lib\site-packages\Box2D\Box2D\_Box2D.pyd

Original comment by snick...@gmail.com on 31 Oct 2008 at 9:21

[GoogleCodeExporter]

Oh, and with Box2D2 backward compat, you'd also have

\Python25\Lib\site-packages\Box2D\Box2D2\__init__.py

Original comment by snick...@gmail.com on 31 Oct 2008 at 9:22

[GoogleCodeExporter]

er, make that

\Python25\Lib\site-packages\Box2D2\__init__.py

Original comment by snick...@gmail.com on 31 Oct 2008 at 9:23

[GoogleCodeExporter]

Yes, .pyd is the binary extension (I guess short for Python DLL?)

And I do want the paths to be exactly as you said, as it's standard that way.

What about the installation of the testbed/etc? As it is now, it installs under
/usr/local/share/box2d for OS X, and PythonDir/box2d for Windows. Not sure if 
those
are the best places, but that's where they were put. Any thoughts?

Original comment by sir...@gmail.com on 31 Oct 2008 at 10:44

[GoogleCodeExporter]

Still there? :(

Original comment by sir...@gmail.com on 15 Nov 2008 at 5:29

[GoogleCodeExporter]

hey, still there, got sidetracked on another project (doing fibreglass layup 
for the thing I was simulating using 
box2d....) but I'll be alive again in a week :)

Original comment by snick...@gmail.com on 18 Nov 2008 at 7:05

[GoogleCodeExporter]

Mostly working, I think. Let's close this for now. Please create a new issue if
something else arises.

Original comment by sir...@gmail.com on 25 Feb 2009 at 6:35

• Changed state: Fixed