Re: [gentoo-dev] python-namespaces.eclass
On 03-04-2011 19:38:17 +0200, Arfrever Frehtes Taifersar Arahesis wrote: I would like to add python-namespaces.eclass. This eclass will be used by a small number of special packages, which will provide Python namespaces. These packages will be used as dependencies of other packages already present in the tree. Could you please update it not to exceed 80 characters? See http://devmanual.gentoo.org/ebuild-writing/file-format/index.html caption Indenting and Whitespace. inherit python # # = HANDLING OF METADATA = # -- Fabian Groffen Gentoo on a different level
Re: [gentoo-dev] Re: python-namespaces.eclass
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Dne 4.4.2011 01:13, Arfrever Frehtes Taifersar Arahesis napsal(a): 2011-04-03 21:28:02 Tomáš Chvátal napisał(a): Dne 3.4.2011 19:38, Arfrever Frehtes Taifersar Arahesis napsal(a): I would like to add python-namespaces.eclass. This eclass will be used by a small number of special packages, which will provide Python namespaces. These packages will be used as dependencies of other packages already present in the tree. Ebuilds using this eclass must set PYTHON_NAMESPACES variable before inheriting this eclass. Example (from net-zope/namespaces-zope): PYTHON_NAMESPACES=Products Shared Shared.DC five +zope zope.app This eclass provides 3 public functions: python-namespaces_src_install() python-namespaces_pkg_postinst() python-namespaces_pkg_postrm() Why you do so much overquoting in the conditions? I like consistency with python.eclass and improved syntax highlighting :) . Improved syntax highlighting? Apart from making it a bit larger that indeed is not a point if bash has to process and strip all the quotes your code is to be slower than the one without them. Why do you die on those arguments, just ignore them... The policy for Python-related eclasses is to not ignore misusage of functions. It is policy defined by you that makes the code larger for no gain. You do the same when you check if the ebuild scope is the same for the function. These checks are not required for any aparent reason. If developer wants to execute src_unpack in src_prepare and shoot himself into his leg eclasses are not the one that should prevent him from doing so. Basically you just add useless logic into the functions, so please do not do that. (this apply for all your patches) You could use some eclass-debug calls (see other eclasses) :) IMHO they are helpless in debugging. 'set -x' enabled by -d option of emerge is more helpful. Ok if you don't feel it helps the development then indeed it is not required to set them :) Why do you call those set_metadata right after its creation and delete it right away, does it save so much time it is better than doing it in global scope? It is used to have appropriate scope for local variables, so that they don't have to be unset manually immediately after the code, in which they should exist. OOk works for me. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.17 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk2Zl7wACgkQHB6c3gNBRYeH9wCfcac24FDG2t8Z1JFZbZ8AQDSv Oq0An3AIfm+JehVVhZksgxmwNfhWi0Sd =0qyh -END PGP SIGNATURE-
Re: [gentoo-dev] python-namespaces.eclass
On Sun, Apr 03, 2011 at 07:38:17PM +0200, Arfrever Frehtes Taifersar Arahesis wrote: I would like to add python-namespaces.eclass. This eclass will be used by a small number of special packages, which will provide Python namespaces. These packages will be used as dependencies of other packages already present in the tree. Ebuilds using this eclass must set PYTHON_NAMESPACES variable before inheriting this eclass. Example (from net-zope/namespaces-zope): namespaces-zope's invocation of the mod_optimize/cleanup crap isn't needed since it's EAPI=3; EAPI3 preserves mtime. What other consumers are expected for this beyond namespaces-zope? PYTHON_NAMESPACES=Products Shared Shared.DC five +zope zope.app This eclass provides 3 public functions: python-namespaces_src_install() python-namespaces_pkg_postinst() python-namespaces_pkg_postrm() -- Arfrever Frehtes Taifersar Arahesis # Copyright 1999-2011 Gentoo Foundation # Distributed under the terms of the GNU General Public License v2 # $Header: $ # @ECLASS: python-namespaces.eclass # @MAINTAINER: # Gentoo Python Project pyt...@gentoo.org # @BLURB: Eclass for packages installing Python namespaces # @DESCRIPTION: # The python-namespaces eclass defines phase functions for packages installing Python namespaces. ^^^ This isn't a useful description. What is it doing to the phase functions? What's the purpose for someone who isn't intimately familiar w/ python setuptools/namespaces? Etc. Seriously, I just spent a good 10 minutes digging through this crap trying to figure out what you were up to- that is *exactly* what the description should convey. Same goes for the code; this needs to be peppered with clear/descriptive comments. The description for PYTHON_NAMESPACES for example on it's own doesn't make clear that it screws with REQUIRED_USE (let alone exactly it's intent). General commentary: If you want to do magic like this, it needs to be documented clearly so everyone else can figure out wtf it is exactly intending on doing (including what it actually is doing)- if it can't be documented to that level it doesn't belong in the tree, only in your personal overlay. As mentioned by others, if you're going to use [[ ]] stop doing unnecessarily quoting w/ that construct- fix your editor if it doesn't color it correctly. ~harring pgpshUXCFSHru.pgp Description: PGP signature
Re: [gentoo-dev] Re: python-namespaces.eclass
2011/4/4 Tomáš Chvátal scarab...@gentoo.org: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Dne 4.4.2011 01:13, Arfrever Frehtes Taifersar Arahesis napsal(a): 2011-04-03 21:28:02 Tomáš Chvátal napisał(a): Dne 3.4.2011 19:38, Arfrever Frehtes Taifersar Arahesis napsal(a): I would like to add python-namespaces.eclass. This eclass will be used by a small number of special packages, which will provide Python namespaces. These packages will be used as dependencies of other packages already present in the tree. Ebuilds using this eclass must set PYTHON_NAMESPACES variable before inheriting this eclass. Example (from net-zope/namespaces-zope): PYTHON_NAMESPACES=Products Shared Shared.DC five +zope zope.app This eclass provides 3 public functions: python-namespaces_src_install() python-namespaces_pkg_postinst() python-namespaces_pkg_postrm() Why you do so much overquoting in the conditions? I like consistency with python.eclass and improved syntax highlighting :) . Improved syntax highlighting? Apart from making it a bit larger that indeed is not a point if bash has to process and strip all the quotes your code is to be slower than the one without them. If you are going to complain about quotes, at least complain sanely. The cost of 'parsing the quotes' is negligible. It is not a question of performance, it is a question of readability and style. Why do you die on those arguments, just ignore them... The policy for Python-related eclasses is to not ignore misusage of functions. It is policy defined by you that makes the code larger for no gain. You do the same when you check if the ebuild scope is the same for the function. These checks are not required for any aparent reason. If developer wants to execute src_unpack in src_prepare and shoot himself into his leg eclasses are not the one that should prevent him from doing so. Basically you just add useless logic into the functions, so please do not do that. (this apply for all your patches) You could use some eclass-debug calls (see other eclasses) :) IMHO they are helpless in debugging. 'set -x' enabled by -d option of emerge is more helpful. Ok if you don't feel it helps the development then indeed it is not required to set them :) Why do you call those set_metadata right after its creation and delete it right away, does it save so much time it is better than doing it in global scope? It is used to have appropriate scope for local variables, so that they don't have to be unset manually immediately after the code, in which they should exist. OOk works for me. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.17 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk2Zl7wACgkQHB6c3gNBRYeH9wCfcac24FDG2t8Z1JFZbZ8AQDSv Oq0An3AIfm+JehVVhZksgxmwNfhWi0Sd =0qyh -END PGP SIGNATURE-
Re: [gentoo-dev] python-namespaces.eclass
2011-04-04 12:04:44 Tomáš Chvátal napisał(a): Dne 4.4.2011 01:13, Arfrever Frehtes Taifersar Arahesis napsal(a): 2011-04-03 21:28:02 Tomáš Chvátal napisał(a): Dne 3.4.2011 19:38, Arfrever Frehtes Taifersar Arahesis napsal(a): I would like to add python-namespaces.eclass. This eclass will be used by a small number of special packages, which will provide Python namespaces. These packages will be used as dependencies of other packages already present in the tree. Ebuilds using this eclass must set PYTHON_NAMESPACES variable before inheriting this eclass. Example (from net-zope/namespaces-zope): PYTHON_NAMESPACES=Products Shared Shared.DC five +zope zope.app This eclass provides 3 public functions: python-namespaces_src_install() python-namespaces_pkg_postinst() python-namespaces_pkg_postrm() Why you do so much overquoting in the conditions? I like consistency with python.eclass and improved syntax highlighting :) . Improved syntax highlighting? Apart from making it a bit larger that indeed is not a point if bash has to process and strip all the quotes your code is to be slower than the one without them. Please don't try to force other developers to use your coding style. -- Arfrever Frehtes Taifersar Arahesis signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] python-namespaces.eclass
2011-04-04 13:48:43 Brian Harring napisał(a): What other consumers are expected for this beyond namespaces-zope? dev-python/namespaces-enthought dev-python/namespaces-peak dev-python/namespaces-repoze net-zope/namespaces-archetypes net-zope/namespaces-grok net-zope/namespaces-plone net-zope/namespaces-silva net-zope/namespaces-zc net-zope/namespaces-z3c The following packages will use both distutils.eclass and python-namespaces.eclass: dev-python/dap dev-python/flask dev-python/logilab-common dev-python/paste net-zope/kss-core -- Arfrever Frehtes Taifersar Arahesis signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Re: rejecting unsigned commits
On Fri, 25 Mar 2011 10:44:31 +0100 Andreas K. Huettel dilfri...@gentoo.org wrote: * the signature proves the key belongs to the e-mail address, nothing else Anyone could generate a signature with one of my @g.o e-mail addresses in it, then pass themselves off as myself, right? If they then trick you into thinking that I sent the mail you received, signed with their key, they're all set. Having the right e-mail address in the key would not improve anything. * the e-mail address is given to the owner of the key during recruitment It's been a while, but I am certain I did not have a @gentoo.org address yet _during_ recruitment, and I was instead asked to provide an address that I _did_ already use. It looks like that still has not changed.[1] Looking at the e-mail from that time, it seems I had been asked to sign my SSH key with it and send it to recruiters@. jer [1] http://www.gentoo.org/doc/en/gnupg-user.xml#doc_chap2
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in dev-python/PyZilla: PyZilla-0.1.0.ebuild ChangeLog metadata.xml
On Sun, 27 Mar 2011 23:28:05 +0200 René 'Necoro' Neumann li...@necoro.eu wrote: Am 27.03.2011 22:44, schrieb Rich Freeman: Well, but you need some way of communicate that certain packages are w/o a proper maintainer. Why else should someone step up? I, for instance, was quite surprised about the list of m-n packages and seeing that quite some packages I use are on that list. I would never had a look at it without this thread (or are users nowadays supposed to check metadata.xml on a regular basis?). I remember distinctly that I once publicly proposed to change http://packages.gentoo.org/ to actually interpret packages' metadata.xml and displaying its formatted contents on every http://packages.gentoo.org/package/CAT/PKG page (notably because the site mentioned and still mentions the last committer at the top of the page, with his or her Gentoo e-mail alias/handle plainly visible, so at the time I envisioned it to prevent people from addressing the wrong developers). metadata.xml is a mere link on every page and doesn't invite anyone to dig deeper, when it could be put to better use. Our bugzilla database already has proper descriptions for every alias we use, so we could reuse that information to improve packages.g.o. (Only, I cannot now find any trace of such a discussion at all, or even the bug report I am quite certain I would have filed about this.) jer
Re: [gentoo-dev] Re: python-namespaces.eclass
On Mon, 4 Apr 2011 01:13:37 +0200 Arfrever Frehtes Taifersar Arahesis arfre...@gentoo.org wrote: The policy for Python-related eclasses is to not ignore misusage of functions. Funny how you keep saying that when it's obvious that the policy is just you. jer
