----- Original Message -----
On Mon, 2012-08-13 at 03:09 -0400, Bohuslav Kabrda wrote:
> ----- Original Message -----
> > On 08/06/2012 04:22 AM, Toshio Kuratomi wrote:
> > > The only distribution that has switched is arch. When they did
> > > there was
> > > a big uproar about how arch was doing something wrong which
> > > eventually
> > > resulted in that PEP.
> >
> > Yeah, we mainly wrote PEP 394 in order to nudge *everyone else*
> > into
> > providing a /usr/bin/python2 symlink to help deal with Arch
> > making
> > their
> > bold leap into the unknown (as well as going on record that we
> > think
> > switching it *right now* is still a bad idea). There's "bleeding
> > edge"
> > and then there's "tap dancing on razor blades in your bare feet"
> > :P
> >
> > To be honest, I expect that the long term outcome will be that
> > "/usr/bin/python" becomes solely the preserve of the OS, with all
> > cross-platform scripts and applications using "/usr/bin/pythonX",
> > software collections, or language level virtual environments.
> >
> > From an end user perspective, having things mostly compatible
> > with
> > both
> > 2 and 3 should come *before* that symlink gets flipped rather
> > than
> > after.
> >
> > Cheers,
> > Nick.
> >
>
> Ok, then I would suggest using Tom Spura's idea about making only
> python2- and python3- packages (maybe with the virtual python-
> provides for python2- packages, as Toshio has mentioned). We could
> target this for F19 and we could also start helping various
> upstreams
> with switching to python 3 and see where this will take us. Does
> that
> sound good?
If we're looking at this kind of change (python2-foo and
python3-foo),
how about some other prefixes:
* python2-debug-foo (or somesuch) for a build of the package
against
the --with-pydebug python2 package
* python3-debug-foo
* pypy-foo for the package built against PyPy
FWIW an old idea I had for revamping how we maintain Python packages
can
be seen here:
http://lists.fedoraproject.org/pipermail/python-devel/2010-March/000213.html
with some further ideas here:
https://fedoraproject.org/wiki/DaveMalcolm/PythonIdeas
(you can tell that page is old, it still mentions Unladen Swallow and
Pynie...)
I still like the basic idea: introduce a tool that captures the info
on
python runtimes for a given release in one place, and use it
programmatically within specfiles to avoid copy&paste. Although the
proposal isn't complete (how to handle exclusions?), I'm still fond
of
it.
Personally, I like the idea. As you say, there are still some issues, but I guess we could
solve those easily.
There is IMHO one downside of this approach - the complexity. I fear that rpm-pyconfig can
be easily taken to such extremes, that we will end up with completely unintelligible
specfiles.
As for supporting more runtimes (e.g. Pypy), I would be very careful about that, as it
might get us overloaded by tons of issues of different packages with different runtimes.
Here is a wild idea: Would it be possible to create a common site-packages directory for
all runtimes? I don't know much about how different runtimes handle bytecode generated
by another runtime etc, but it may be worth looking into, if we want to support more
runtimes with our packages.
Another idea would be to use the Software Collections tool seen
here:
https://fedorahosted.org/SoftwareCollections/
I known that people within Red Hat have been looking at using that in
the RHEL context, and some of that is likely to be appropriate for
EPEL
too - though AIUI it's a shift in model from one build per src.rpm to
multiple builds per src.rpm
I've already done my bit of SCL packaging, so here are my 50 cents :)
- How exactly would you apply SCLs in our case? I like the SCL concept (obviously :) ),
but if you package e.g. Python 3 as an SCL, then you're going to have a hard time
convincing someone to switch their application to it. Maybe packaging all the -debug
builds for a single runtime in an SCL might be a good idea? E.g. have one srpm, that would
produce optimized build if built out of SCL and debug build if built with SCL.
- SCLs are currently not allowed in Fedora [1] (I'm not sure why, maybe Toshio can
explain why FPC chose to forbid them).
- If anyone is interested in an example how things could work out, drop me a line, I can
create a simple example.
Hope this is helpful
Dave
_______________________________________________
python-devel mailing list
python-devel(a)lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/python-devel
--
Regards,
Bohuslav "Slavek" Kabrda.
[1]
https://fedoraproject.org/wiki/Packaging:Guidelines#Software_Collection_M...