Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

pygame_sdl2 doesn't build with 'sdist' command on windows #93

Open
MyreMylar opened this issue Apr 12, 2018 · 1 comment
Open

pygame_sdl2 doesn't build with 'sdist' command on windows #93

MyreMylar opened this issue Apr 12, 2018 · 1 comment

Comments

@MyreMylar
Copy link
Contributor

MyreMylar commented Apr 12, 2018

I've been poking at this problem this afternoon as I think it is perhaps the root of why there isn't a version of pygame_sdl2 that we can just grab via pip on windows.

To see the problem, instead of running the normal:
python setup.py install

command, run:
python setup.py sdist

and then try to install the resulting tarball with pip like so:
pip install dist\pygame_sdl2-2.1.0.tar.gz

and you will quickly come a cropper.

Poking into the (pretty complicated!) setup.py file it looks like the issues stem from the code that is being used to copy the windows dependencies from where you plonk them in your root pygame_sdl2 directory over to your install location.

Once you wade through some unhandled exceptions (it seems that pip expects the setuplib.py file to handle it's own exceptions and won't tolerate them bubbling up to setup.py) you get to the meat of the problem which is that the windows dependencies that the setup.py code wants to copy to your install directory with shutil.copy aren't being bundled in to the tarball.

I'm far from an expert in these matters having only really looked into it for the first time today, but I feel like there has been some confusion over the role of the setup.py file in installing python packages somewhere along the way. It appears that code in setup.py is designed to be run on already packaged up python projects to do some additional setup, but the windows dependency code in there right now is designed to add data from a source directory (that doesn't exist in the package) to a package.

It works with the rough and ready python setup.py install because the user drags the windows dependency directory into the package before the script is run and the package directory is synonymous with our source directory.

What probably needs to change is either that we include the windows dependency files copy from location in the package (pygame_sdl2_windeps) or we move the code that copies files from the windows dependency directory to some place other than the setup.py file.

I'm happy to poke at this further, but I really have very little idea what I'm doing.

@MyreMylar
Copy link
Contributor Author

MyreMylar commented Apr 12, 2018

Hah,

Right after posting I figured out a local work around.

I'm not sure if this will help with making pygame_sdl2 generally distributable on windows but it does solve the issues with running setup.py and fixes the python include issues. The solution turned out to be tucked away over here:
https://pythonwheels.com/

I've used wheel files before but had no idea they would solve this particular issue, but there it is right in the Advantages section of the front page. Anyway to build and install pygame_sdl2 properly on windows after following the other steps in the readme, try this in an administrator cmd window:

pip install wheel

then something like:

python setup.py sdist bdist_wheel pip install dist\pygame_sdl2-2.1.0-cp36-cp36m-win32.whl

The exact name of the .whl file will depend on your version of python. You may need to delete your current install of pygame_sdl2 if you already installed it.

With this method pip correctly installs the python headers so that IDE's like PyCharm can find them and your code highlighting will no longer be full of annoying warnings.

Perhaps a good partial solve would be to just add this wheel method of building and installing on windows to the GitHub readme?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant