Is it possible to deliver different source distributions for different Python versions?
jenesuispasdave at gmail.com
Tue Apr 7 02:53:32 CEST 2015
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:
> 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.
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.
More information about the Python-list