Recently while working on yapsy, I fell on a few subtleties related to the creation of Python packages.
I use distutils obviously and the generated packages are uploaded on http://pypi.python.org, but I was struggling with the following problems:
- the data files used by my unit-tests were not packaged
- I couldn't get pypi to understand that one of the source package was for Python2 installations while the other was for Python3 so that only one of them was displayed on the package page, and of course the few users yapsy has kept complaining that the code didn't work for obvious reasons like importing 'configparser' whereas this module is spelled 'ConfigParser' in Python2
The solutions to both problems now seem obvious to me, but were strangely difficult to come across on the web.
The solution of the first problem is clearly to use the MANIFEST.in file to list all data files that need to be packaged. Except that for me MANIFEST.in was one of these files that may get generated by distutils (hey ! it's not even a Python file) and writing one by hand looked like a dirty hack to me... Talking about dirty hacks, I'm also much more accustomed to use py2exe to package applications which actually requires a lot of hacks but all of them are to be written in Python, this showed me the wrong way as it seems.
What saved me is the apparently unfinished packaging documentation by Tarek Ziadé:
The Hitchhiker's Guide to Packaging. It's very clear in there that MANIFEST.in is a perfectly legimitate member of the package set of files next to LICENSE.txt and README.txt.
The second problem about simultaneous packaging of a library's Python 2 and 3 sources, was somehow harder though and even less documented on the web (considering the number of my google search failures).
I eventually got luck and found a site that not only talked about it (which was already pretty rare) but also gave detailed advises and samples about the several ways to solve the problem ! Everything is on the judiciously named"
Distribution" page of the even more judiciously named
Porting to Python3 website.
By the way, I chose for yapsy to use the brute force strategy where both sources (python2 and 3) of the lib are gathered in the same source package, and the setup script decides at installation time which set of sources to use. To get this a little easier at release time, I wrote a shell script and a few lines of Python that can be read there:
