----- Original Message ----- > 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 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.
_______________________________________________ python-devel mailing list python-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/python-devel
