From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from pigeon.gentoo.org ([208.92.234.80] helo=lists.gentoo.org) by finch.gentoo.org with esmtp (Exim 4.60) (envelope-from ) id 1S2q5i-0003Ni-F3 for garchives@archives.gentoo.org; Wed, 29 Feb 2012 20:25:38 +0000 Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id E3FAFE09DD; Wed, 29 Feb 2012 20:25:22 +0000 (UTC) Received: from smtp.gentoo.org (smtp.gentoo.org [140.211.166.183]) by pigeon.gentoo.org (Postfix) with ESMTP id 4098AE097E for ; Wed, 29 Feb 2012 20:24:55 +0000 (UTC) Received: from [10.0.0.62] (89-74-61-34.dynamic.chello.pl [89.74.61.34]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: nelchael) by smtp.gentoo.org (Postfix) with ESMTPSA id 20B051B401E; Wed, 29 Feb 2012 20:24:53 +0000 (UTC) Message-ID: <4F4E8991.8040907@gentoo.org> Date: Wed, 29 Feb 2012 21:24:49 +0100 From: Krzysztof Pawlik Organization: Gentoo User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0.1) Gecko/20120213 Thunderbird/10.0.1 Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-dev@lists.gentoo.org Reply-to: gentoo-dev@lists.gentoo.org MIME-Version: 1.0 To: gentoo-dev@lists.gentoo.org CC: Alexandre Rostovtsev Subject: Re: [gentoo-dev] New eclass for Python References: <4F4D4380.9070909@gentoo.org> <1330545088.15103.62.camel@rook> In-Reply-To: <1330545088.15103.62.camel@rook> X-Enigmail-Version: 1.3.5 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="------------enig1328D9DAA3FA0BFAEC112031" X-Archives-Salt: 8594d9d2-bcf4-4d4c-b463-4d9a2f32ead3 X-Archives-Hash: dcc9fd20aab3d28a58ed2148b5edc958 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig1328D9DAA3FA0BFAEC112031 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 29/02/12 20:51, Alexandre Rostovtsev wrote: > On Tue, 2012-02-28 at 22:13 +0100, Krzysztof Pawlik wrote: >> Hello, >> >> After some work during weekend on Python packages I've decided to star= t a >> rewrite of Python/distutils eclass for installing Python packages. My = main goal >> was simplicity and functionality similar to ruby-ng.eclass (thanks Rub= y team for >> your great work!). Python team members already contributed comments an= d >> suggestions and helped me to make the eclass better, thank you! >> >> Highlights: >> - *SIMPLE*next >> - uses PYTHON_TARGETS use-expand (no more python-updater, whoooo!) >> - EAPI4 required, uses REQUIRED_USE >> - <400 lines of code including documentation >> - should work for >95% of packages (my educated guess) >> - did I mention it's *SIMPLE*? >> - easy to maintain & read so it's also easy to use >> >> Important thing: I'm not aiming at having 100% functionality of curren= t >> python.eclass+distutils.eclass in the new one, I think that simplicity= is more >> important that supporting every possible, obscure case that's out ther= e. >> >> I'm attaching the eclass itself and two ebuilds using it, code is also= available >> in my overlay at http://git.overlays.gentoo.org/gitweb/?p=3Ddev/nelcha= el.git;a=3Dsummary >> >> If there are no objections then during the weekend (March 3, 4) I will= add this >> to portage (after finishing remaining TODO items, PyPy requires 4G of = RAM(!!)). >=20 > The proposed eclass omits three features from python.eclass which are > heavily used in the gnome stack. Correct me if I'm wrong, but Gnome doesn't use standard distutils? Regardless of this eclass you can still use python.eclass, it not going a= nywhere anytime soon (just like I wrote in one of previous e-mails). > First, it does not set EPYTHON, which is a problem for the many package= s > whose build systems execute /usr/bin/python and assume that it's a > generic python2 or the same version of python2.x for which the package > is being built. Setting EPYTHON is not a problem -- just another variable. > Second, there doesn't seem to be any support for packages that do not > install in python's site-packages and do not allow multiple python ABIs= =2E > If I have, for example, a package that installs python modules > in /usr/lib/appname or /usr/share/appname, how can I specify that > PYTHON_TARGETS=3D"python2.6" or "python2.7" or "python3.2" is allowed, = but > something like PYTHON_TARGETS=3D"python2.7 python3.2" is not? You're correct, note that I've stressed that this eclass is mainly for distutils-based packages. I'm not using Gnome, so can you provide some pa= ckage examples that I can look at? If package decides to use given language then please, please play by the = rules set by the rest of world (Ruby -> gems, Python -> distutils, Perl -> CPAN= , PHP -> PEAR). I don't like installing Python code outside of site-packages, the only ex= ception to that rule is portage (at least for now). > Third, python-distutils-ng_doscript() installs only one file at a time > (no built-in support for multiple files at a time or for recursing > through a directory tree), Yes, that why bash has `for' loop ;) > installs it only in /usr/bin (a package might > want it in e.g. /usr/libexec or /usr/share/appname/scripts) Yes, I might add --destdir (or something like that) later on. > and always > creates scriptname-IMPLEMENTATION (polluting tab-completion in /usr/bin= > for the common case of programs that do not support multiple python > ABIs). As a result, it is far less useful than python.eclass's > python_convert_shebangs(). Yes, that "pollutes" this name space, but I'm not buying this argument. D= o you know how CVS and .svn "pollute" my tab-completion list? I even set FIGNOR= E so I can live with it. I'd be happy to hear how to solve this - what prefix or suffix to use? On= e way would be quite trivial: if only one implementation is enabled do not crea= te script-${impl}, go with single file, does that sound good? --=20 Krzysztof Pawlik key id: 0xF6A80E46 desktop-misc, java, vim, kernel, python, apache... --------------enig1328D9DAA3FA0BFAEC112031 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.18 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBCgAGBQJPTomRAAoJEBZyv1r2qA5GL+QH/RuuYWxa4S0O/4CJrmePZz6u ss0mwIN7RWE+oQwPUjgtQNIQcB1omY8cN2K8uJVz3iLlFS+zIsrPEoDgak8AGIdq uuvEydAIg4Ky6a4+1LzoZ7nGb4i9AyIsqKd0qHpUEPIyHUZuvflpRaS6OpFEWlzX iovTNhM0EmuRJEwBWAyHOruZeqwDKimSuLI+3kQtvJf0jnMpRjGeoNT4NudH76Yd eGKwdzu8ERaLdZPNK//rUkKcZoN/V1TAtIYHTvzI/ZbN9dvffC5e/Jdno/BgL9/8 HnDapXGHcwR/ZtSZsw84j6SEWpmPt/q5k34W7ZDh5Jl5VGjoB3otgOmF4GfLyEU= =xoqH -----END PGP SIGNATURE----- --------------enig1328D9DAA3FA0BFAEC112031--