Renaming Feature for F19 [was: Re: Switching to Python 3]

[Bohuslav Kabrda]

----- Original Message -----

> On Thu, Aug 23, 2012 at 8:53 AM, Bohuslav Kabrda < bkabrda at redhat.com
> > wrote:

> > ----- Original Message -----
> 
> > > On Tue, Aug 14, 2012 at 9:42 AM, Nick Coghlan <
> > > ncoghlan at redhat.com
> > > >
> 
> > > wrote:
> 
> > > > However, I think it's enough to place a clear upper limit on
> > > > the
> 
> > > > number
> 
> > > > of runtimes to be supported (where 'x' is the relevant minor
> 
> > > > version
> 
> > > > packaged in the Fedora repos): CPython 2.x, PyPy 1.x, Python
> > > > 3.x
> 
> > > > (with
> 
> > > > shared site-packages)
> 
> > >
> 
> > > I don't know if pypy1-foo makes sense or how they want to support
> 
> > > python2 and python3 at the same time. But I'm all for pypy1-foo
> > > to
> > > be
> 
> > > on the save side...
> 
> > >
> 
> > > One thing, that comes to my mind:
> 
> > > Should it be python2-foo or cpython2-foo?
> 
> > >
> 
> > > Otherwise, I went ahead and created a feature page:
> 
> > > https://fedoraproject.org/wiki/Features/PythonNamingDependingOnImplementation
> 
> > > Feel free to add yourself to the "owner" list and change it, when
> 
> > > there is something missing.
> 
> > >
> 
> > > I would propose, that we agree to a IRC meeting, where we can
> > > discuss
> 
> > > possible differences or do you think anything is sorted out now
> > > and
> 
> > > the feature is "sane" for anyone?
> 
> > >
> 
> > > Greetings,
> 
> > > Tom
> 

> > Nice :)
> 
> > Some comments:
> 
> > - The naming guidelines say, that if a package contains "py" in its
> > name, it can be used without the "$runtime-" prefix (e.g. pygtk). I
> > think we may want to cancel this rule, as it would be unclear, why
> > we have e.g. pygtk and python3-pygtk (in some point this would have
> > to change somehow, anyway). We should just name _all_ the packages
> > $runtime-$name.
> 
> > - Another thing is, that some packages already contain "python-" in
> > their upstream name. For these, I'm not sure how to proceed - the
> > best way is probably to replace the "python-" with "$runtime-",
> > although we'd be changing upstream name by this. Thoughts?
> 

> Both +1

> > - As I understand, we will have "python-$name" virtual provides for
> > python2 packages. Are we going to throw them away eventually or
> > transfer them to python3 packages once the time is right? I'd
> > probably suggest dropping them after some time (next release after
> > we finish all this renaming work?), although it may be somehow
> > confusing to the users (until they get used to it).
> 

> I think it's useful to have something like
> $default_implementation-$name, so it's easier to change the
> $default_implementation and just rebuild all packages. When
> maintainers want to do the switch to python3 (or pypy or whatever)
> at the same time, when e.g. /usr/bin/python changes, this is a nice
> way to do it.

> Maybe we could even do this in a macro, e.g.
> %provide_python_package $packagename $implementation_from_spec_file

> This can then provide python-$packagename, when
> $implementation_from_spec_file is equals to the generic defined
> default and do nothing otherwise. This way, moving the provides
> python-foo from python2 to another python implementation happens
> with a simple rebuild (But does anything a bit more complex).

> > - Why exactly should pypy be pypy1? Are we also planning having
> > more
> > of these in parallel?
> 

> Just in case, that pypy2 will support python3 and NO python2 and will
> be backward incompatible? It's a proposal and can also be removed,
> if necessary.

> > - As for the python2-foo/cpython2-foo, I'd stay with python2-foo.
> > It's just the good old Python, this would be very confusing, I
> > think
> > (also, the upstream name is Python rather than cPython, isn't it?).
> 

> Ok. Just that plain "python" is considered as "default
> implementation" and "python2" might be considered as "default
> implementation 2". This might cause confusion too. But I'd prefer to
> keep python2-foo too.

> > This is going to be lots of work, basically all the packages will
> > need to be re-reviewed. I'd suggest having a meeting about it,
> > after
> > we clarify the most important points here and then start, the
> > sooner
> > the better.
> 

> That's why, I want to try bypassing the reviews like mingw once did.
> It will still be plenty of work to rename anything, but at least the
> re-reviews might be dropped...

> How about next Wed 8/29 at 16-17 UTC for the first meeting?
> http://fedoraproject.org/wiki/Meeting_channel

Did any meeting take place? I couldn't join, unfortunately. If the meeting didn't take place, would everyone agree to arrange a new one? Say, two weeks from now, so everyone can make some time in advance... 
So my proposal: 
Tue 9/18 at 16-17 UTC 

> About Jython:
> I think, we should find an agreement, what counts as "allowed python
> implementation you are free to choose from", e.g. the python2-debug
> discussion. We should add that to the agenda for the IRC meeting and
> discuss then about Jython. (I'd be +0 in this case... :))

Just BTW, I am definitely +1 on Jython - Java implementations of interpreted languages have great potential in threading (and therefore scaling) and we should be definitely aiming at them. But let's leave that to the meeting. 

> Greetings,
> Tom

-- 

Regards, 
Bohuslav "Slavek" Kabrda. 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.fedoraproject.org/pipermail/python-devel/attachments/20120904/68eb43a6/attachment.html>