On Thu, Aug 23, 2012 at 8:53 AM, Bohuslav Kabrda <bkab...@redhat.com> wrote:
> ----- Original Message ----- > > On Tue, Aug 14, 2012 at 9:42 AM, Nick Coghlan <ncogh...@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
_______________________________________________ python-devel mailing list python-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/python-devel
