On Monday, April 6, 2015 at 12:47:05 AM UTC-5, Stefan Behnel wrote: > Dave Hein schrieb am 05.04.2015 um 22:38: > > I would like to distribute a python package with different code for > > Python 2.* than for Python 3.*. (Mostly this is because of different > > unicode string handling). > > > > There is nothing in to setuptools or PyPi that directly supports > > this scenario. > > > > But perhaps there could be some script run at install time that moves > > the correct source code to the right location? In other works, if I > > included both source code versions in the distribution (in a src2 and > > a src3 subdirectory) then a function invoked at install time could > > detect the python version and copy the appropriate source code to the > > right location. > > > > Is that at all possible? Is there some install time hook that lets me > > supply custom installation code? > > Sure. You can simply change the directory in which distutils looks for your > Python code: > > https://docs.python.org/2/distutils/setupscript.html#listing-whole-packages > > However, in general, you shouldn't be doing this. It's usually easier > (definitely in the long-term) to keep your sources cross-Py2.x/3.x > compatible, maybe with the help of tools like "six" or "python-future", > than to try to keep separate source trees in sync. > > http://python-future.org/ > > Stefan
I understand. What got me going down the two-source-trees path is that the unittest support isn't cross compatible ... the way I'm using mocks doesn't translate between 2.7 and 3.3. I also like having really clean 3.x code and just keeping the warts confined to the 2.x branch. I use the futures stuff in the 2.x branch to keep it as close as possible to the 3.x branch, but there are still enough differences that I have to mung the 3.x changes just a little when I merge them back into the 2.x branch. -- Dave Hein -- https://mail.python.org/mailman/listinfo/python-list
