----- 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@lists.fedoraproject.org > https://admin.fedoraproject.org/mailman/listinfo/python-devel -- Regards, Bohuslav "Slavek" Kabrda. [1] https://fedoraproject.org/wiki/Packaging:Guidelines#Software_Collection_Macros _______________________________________________ python-devel mailing list python-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/python-devel