On Fri, 2010-01-15 at 10:55 -0500, Toshio Kuratomi wrote: > On Fri, Jan 15, 2010 at 12:31:41PM +0100, Thomas Spura wrote: > > Am Donnerstag, den 14.01.2010, 22:54 -0500 schrieb Toshio Kuratomi: > > > On Thu, Jan 14, 2010 at 04:56:23PM -0500, David Malcolm wrote: > > > > python3 is in rawhide and I'm hoping to build out the Python 3 stack > > > > (help would be most welcome!) > > > > > > > > I've run into a snag with the plan of building out parallel python 2 and > > > > python 3 stacks [1]: What do we do about executables that live > > > > in /usr/bin ? > > > > > > > The first and most important question is why do we need a script for each > > > stack? I think the default should be to only have one version of scripts > > > that either require python2 or python3. Only in cases where the python2 and > > > python3 versions do different things should we have both. > > > > We need a script for each stack to test, if the programm also works with > > python3. If some time in the future, everything works with python3, we > > could swap the defaults and the scripts run with python3 on standard and > > the python2 executables become /usr/bin/foo2 (or something like that). > > And laterly maybe remove again the foo2 executable, if everything works. > > > > If the scripts are not for each stack, we'll stick with to python2 > > forever. > > > > Or how would you to the swap? (Sure it's to early to do it now, but some > > time it needs to be done.) > > > This reasoning (needed for testing) doesn't appeal to me at all. The > general case should be that we switch applications in rawhide from python2 > to python3. Test those packages in rawhide. If it works, then the nex > version of Fedora ships with those scripts using the python3 interpreter. I ran this on my F-12 laptop (running a mix of software, with a local build of python3 and python3-setuptools): [david@brick ~]$ (for f in /usr/bin/* ; do (file --brief $f | grep python > /dev/null) && echo $f ; done) > python-executables.txt [david@brick ~]$ wc -l python-executables.txt 142 python-executables.txt I think that we can usefully split these python scripts into two categories, as follows. For those in the first category it makes sense to keep both python 2 and python 3 versions around. For those in the second, we'd want to gradually move them over to Python 3 as the dependencies are ported (which in itself is a large task...) = Support files for the Python language = These scripts are for working with the language itself, or a stack/major library built on top of Python; a Python developer would typically want both versions available for use, or for testing: /usr/bin/2to3 /usr/bin/2to3-3 /usr/bin/bpython /usr/bin/coverage /usr/bin/django-admin /usr/bin/easy_install /usr/bin/easy_install-2.6 /usr/bin/easy_install-3.1 /usr/bin/g-ir-scanner /usr/bin/idle /usr/bin/idle3 /usr/bin/pydoc /usr/bin/pydoc3 /usr/bin/pygtk-demo /usr/bin/python2 /usr/bin/python2.6-config /usr/bin/python3.1-config /usr/bin/python3-config /usr/bin/python-config /usr/bin/testosterone = Script that "merely" uses Python = These are "merely" scripts that use Python, rather than those for poking at Python. I think these should gradually be ported over to Python 3 as the underlying dependencies are ported: /usr/bin/alacarte /usr/bin/audit2allow /usr/bin/bittorrent-console /usr/bin/bittorrent-curses /usr/bin/bittorrent-tracker /usr/bin/blueman-adapters /usr/bin/blueman-applet /usr/bin/blueman-assistant /usr/bin/blueman-browse /usr/bin/blueman-manager /usr/bin/blueman-sendto /usr/bin/blueman-services /usr/bin/bodhi /usr/bin/bugzilla /usr/bin/bzr /usr/bin/canto /usr/bin/canto-fetch /usr/bin/canto-inspect /usr/bin/cftp /usr/bin/changetracker-console /usr/bin/chcat /usr/bin/ckeygen /usr/bin/conch /usr/bin/debuginfo-install /usr/bin/dtrace /usr/bin/fedora-cert /usr/bin/fedora-cvs /usr/bin/fedora-hosted /usr/bin/fedora-packager-setup /usr/bin/find-repos-of-install /usr/bin/git-cola /usr/bin/gnome-about /usr/bin/gnome-sudoku /usr/bin/gtester-report /usr/bin/gtk-builder-convert /usr/bin/gtkdoc-depscan /usr/bin/gupnp-binding-tool /usr/bin/hg /usr/bin/hg-ssh /usr/bin/im /usr/bin/invest-chart /usr/bin/iotop /usr/bin/istanbul /usr/bin/koji /usr/bin/ksflatten /usr/bin/ksvalidator /usr/bin/ksverdiff /usr/bin/launchmany-console /usr/bin/launchmany-curses /usr/bin/libglade-convert /usr/bin/lore /usr/bin/mailmail /usr/bin/maketorrent-console /usr/bin/manhole /usr/bin/mercurial-convert-repo /usr/bin/mktap /usr/bin/msgfmt.py /usr/bin/msghack /usr/bin/ndiff /usr/bin/needs-restarting /usr/bin/nosetests /usr/bin/package-cleanup /usr/bin/plague-client /usr/bin/ps_mem.py /usr/bin/purple-remote /usr/bin/purple-url-handler /usr/bin/pygettext.py /usr/bin/pygmentize /usr/bin/pyhtmlizer /usr/bin/repoclosure /usr/bin/repodiff /usr/bin/repo-graph /usr/bin/repomanage /usr/bin/repoquery /usr/bin/repo-rss /usr/bin/reposync /usr/bin/repotrack /usr/bin/rpmdev-bumpspec /usr/bin/rpmdev-checksig /usr/bin/rpmdev-rmdevelrpms /usr/bin/rpmdev-vercmp /usr/bin/rpmdiff /usr/bin/rst2html /usr/bin/rst2latex /usr/bin/rst2newlatex /usr/bin/rst2pseudoxml /usr/bin/rst2s5 /usr/bin/rst2xml /usr/bin/rstpep2html /usr/bin/rsvg /usr/bin/sandbox /usr/bin/sealert /usr/bin/sepolgen-ifgen /usr/bin/smtpd.py /usr/bin/sphinx-autogen /usr/bin/sphinx-build /usr/bin/sphinx-quickstart /usr/bin/squeal /usr/bin/system-config-firewall /usr/bin/system-config-firewall-tui /usr/bin/tap2deb /usr/bin/tap2rpm /usr/bin/tapconvert /usr/bin/tkconch /usr/bin/torrentinfo-console /usr/bin/trial /usr/bin/twistd /usr/bin/urlgrabber /usr/bin/verifytree /usr/bin/virt-clone /usr/bin/virt-convert /usr/bin/virt-image /usr/bin/virt-install /usr/bin/xml2po /usr/bin/xmlproc_parse /usr/bin/xmlproc_val /usr/bin/yum /usr/bin/yum-builddep /usr/bin/yum-debug-dump /usr/bin/yum-debug-restore /usr/bin/yumdownloader /usr/bin/yum-groups-manager How does this sound? Dave -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel
