2:39 p.m.
On Tue, Aug 14, 2012 at 9:42 AM, Nick Coghlan <ncoghlan(a)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/PythonNamingDependingOnImplementa...
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
1:53 a.m.
----- Original Message -----
On Tue, Aug 14, 2012 at 9:42 AM, Nick Coghlan
<ncoghlan(a)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/PythonNamingDependingOnImplementa...
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?
- 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).
- Why exactly should pypy be pypy1? Are we also planning having more of these in
parallel?
- 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?).
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.
Thanks for creating the feature page!
Slavek.
--
Regards,
Bohuslav "Slavek" Kabrda.
3:05 a.m.
On Thu, Aug 23, 2012 at 8:53 AM, Bohuslav Kabrda <bkabrda(a)redhat.com> wrote:
----- Original Message -----
> On Tue, Aug 14, 2012 at 9:42 AM, Nick Coghlan <ncoghlan(a)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/PythonNamingDependingOnImplementa...
> 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
7:34 a.m.
----- Original Message -----
On Thu, Aug 23, 2012 at 8:53 AM, Bohuslav Kabrda <
bkabrda(a)redhat.com
> wrote:
> ----- Original Message -----
> > On Tue, Aug 14, 2012 at 9:42 AM, Nick Coghlan <
> > ncoghlan(a)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/PythonNamingDependingOnImplementa...
> > 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.
2:53 a.m.
Thomas Spura wrote:
On Tue, Aug 14, 2012 at 9:42 AM, Nick Coghlan
<ncoghlan(a)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/PythonNamingDependingOnImplementa...
Feel free to add yourself to the "owner" list and change it, when
there is something missing.
What about Jython?
--
Zart
4249
days inactive
4262
days old
python-devel@lists.fedoraproject.org
4 comments
3 participants
participants (3)
-
Bohuslav Kabrda -
Konstantin Zemlyak -
Thomas Spura