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

Jesse Keating jkeating at redhat.com
Sat Jan 16 20:53:04 UTC 2010


On Sat, 2010-01-16 at 13:09 -0500, Toshio Kuratomi wrote:
> On Sat, Jan 16, 2010 at 12:45:24PM +0200, Ville Skyttä wrote:
> > 
> > But what's the benefit of alternatives for this?  Is the intent to provide 
> > sysadmins a way to change which python version of an app would be the system 
> > default?
> > 
> > If not, why not just pick what we want to be the default for each app, and use 
> > a plain old symlink in packages to point to it?  Changing what we want to be 
> > the default would require package updates anyway, and it seems to me that 
> > alternatives just complicates things and provides people a way to shoot 
> > themselves in the foot, e.g prevent that default change from happening when 
> > that package update lands (in addition to changing it at will without any 
> > package updates in question) which might not be a good thing.
> 
> Additionally, I think alternatives would only work for exactly the scripts
> that I think don't need to have a python2 and python3 version.  ie: The
> scripts that do exactly the same thing whether they're run via pythn2 or
> python3.  AFAICS, we should just have those scripts/packages choose to
> install the python2 version xor the python3 version.  The end user gets no
> visible changes (except maybe different bugswhich we are supposed to just
> fix).  In cases where the two scripts do different things, alternatives
> shouldn't be used anyway.
> 

I wasn't really suggesting we use alternatives, I was merely pointing
out the way in which alternatives could work and also pointing out the
alternative of environment modules.

-- 
Jesse Keating
Fedora -- Freedom² is a feature!
identi.ca: http://identi.ca/jkeating
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part
Url : http://lists.fedoraproject.org/pipermail/devel/attachments/20100116/e4eb541b/attachment.bin 


More information about the devel mailing list