> > Since nobody knows so far I walked the path of no risk and sticked to python > 2.3. However, for myself there is no problem at all since I own a legal copy > of Visual Studio.Net 2003. So for me, redistribution is not a problem at > all. I can't speak of anyone else that might be using python, though. >
I wonder what other open source projects do. Also applications not using embedded python, but using py2exe to create a standalone executable from their python sources, likely will have the same problem. Anyway, I asked in #python about this before, but got no replies. (And writing to their mailing list will likely have no different answers than the links you gave.) > So if we come to an agreement that the windows package should be shipped > with a more up-to-date python DLL, just tell me and it will be done. But I > want it to be a matter of widespread agreement before I do that. I never > used python and I don't know which version is most appropriate. If we come > to a conclusion here just let me know and I will make it happen. > I can see five options how to proceed right now: 1. We include the DLL - it comes with the official python installer, so it can't be that problematic to re-distribute it with the Windows installer, if otherwise it doesn't work. 2. Stay with python 2.3. But I'd say, in the long term, staying with an outdated, unmaintained library always will lead to problems.. although, Mordante tested a recent trunk version with Python 2.3 and it does work. 3. Get Python to compile with mingw, or hack up the python sources themselves and redistribute a version compiled from that, or use another python version like stackless which does not depend on an extra Microsoft DLL under Windows. 4. A fourth option would be to ask users to separately download that DLL, in case it is not already present on their system. 5. Don't enable Python support in Windows builds, and in the long term, phase out the Python support in favor of Lua. Option 4 of course is very bad, even if the percentage of systems without that DLL is low. Unless maybe, it is a dll present on all XP and Vista systems, just not on older ones - but from what I've read so far that's not the case. Option 2 also is bad. If we can't use Python 2.4/2.5 or newer, then I think it's a strong argument for switching to Lua instead. Same for option 3 - getting the current Python-AI API working in Lua likely is an easier task than hacking up the Python sources. So, personally, I'd go with option 1 for now. And maybe over time some other project (or Python's windows devs) will do option 3 for us, or someone will write a Lua implementation, or maybe Vista ships that DLL by default.. either of them will make the problem solve itself eventually. -- Allefant _______________________________________________ Wesnoth-dev mailing list [email protected] https://mail.gna.org/listinfo/wesnoth-dev
