Globally-visible executables with parallel python 2 and python 3 stacks

Toshio Kuratomi a.badger at gmail.com
Fri Jan 15 15:55:05 UTC 2010


On Fri, Jan 15, 2010 at 12:31:41PM +0100, Thomas Spura wrote:
> Am Donnerstag, den 14.01.2010, 22:54 -0500 schrieb Toshio Kuratomi:
> > On Thu, Jan 14, 2010 at 04:56:23PM -0500, David Malcolm wrote:
> > > python3 is in rawhide and I'm hoping to build out the Python 3 stack
> > > (help would be most welcome!)
> > > 
> > > I've run into a snag with the plan of building out parallel python 2 and
> > > python 3 stacks [1]: What do we do about executables that live
> > > in /usr/bin ?
> > > 
> > The first and most important question is why do we need a script for each
> > stack?  I think the default should be to only have one version of scripts
> > that either require python2 or python3.  Only in cases where the python2 and
> > python3 versions do different things should we have both.
> 
> We need a script for each stack to test, if the programm also works with
> python3. If some time in the future, everything works with python3, we
> could swap the defaults and the scripts run with python3 on standard and
> the python2 executables become /usr/bin/foo2 (or something like that).
> And laterly maybe remove again the foo2 executable, if everything works.
> 
> If the scripts are not for each stack, we'll stick with to python2
> forever.
> 
> Or how would you to the swap? (Sure it's to early to do it now, but some
> time it needs to be done.)
> 
This reasoning (needed for testing) doesn't appeal to me at all.  The
general case should be that we switch applications in rawhide from python2
to python3.  Test those packages in rawhide.  If it works, then the nex
version of Fedora ships with those scripts using the python3 interpreter.

-Toshio
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
Url : http://lists.fedoraproject.org/pipermail/devel/attachments/20100115/014813f4/attachment.bin 


More information about the devel mailing list