Is it possible to deliver different source distributions for different Python versions?

[Dave Hein]

On Sunday, April 5, 2015 at 8:01:22 PM UTC-5, Steven D'Aprano wrote:
> On Mon, 6 Apr 2015 06:38 am, Dave Hein wrote:
> 
> > 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?
> 
> I'm not aware of any standard solution to that, but I'm not a setuptools
> expert. setup.py files are Python code, so you can put any code you like in
> them. But, as far as I am concerned, having the installer pick and choose
> what source files to include is not a good solution. Instead, you should
> pick one of these two alternatives:
> 
> 
> (1) Supply a separate package for 2.x and 3.x, each with their own
> installer. The installer confirms that it is running under the correct
> version of Python, and just installs.
> 

Yep. That's what I'm doing now. Two distinct packages on PyPi.

> 
> (2) Or supply a single package with a single installer that works under both
> 2.x and 3.x. (This is my preference.)
> 
> One way of handling the second case is to only support 3.3 or better: that
> way, you can still use u"..." for Unicode strings. Hardly anyone used 3.1
> or 3.2, and 3.0 is no longer supported, so it is quite reasonable to insist
> people upgrade to 3.3.
> 

There is other code that doesn't translate cleanly between 2.x and 3.x. Specifically the unittest tests and unittest.mock usage. That's mainly why
I don't have one source tree.

> Another way to handle the second case is to use conditional imports:

Hmm. Maybe I can figure out how to isolate the 2.x weirdness into a 
separate package and conditionally import the 3.x version vs. 2.x version.
I'll look into that.

Thanks.

> 
[snip]
> 
> -- 
> Steven

--
Dave Hein