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

[Thomas Spura]

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

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... :))

Greetings,
    Tom
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.fedoraproject.org/pipermail/python-devel/attachments/20120823/3c625e0f/attachment.html>