FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Gentoo > Gentoo Development

 
 
LinkBack Thread Tools
 
Old 04-04-2011, 08:20 AM
Fabian Groffen
 
Default 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
 
Old 04-04-2011, 10:04 AM
Tomáš Chvátal
 
Default 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/

iEYEARECAAYFAk2Zl7wACgkQHB6c3gNBRYeH9wCfcac24FDG2t 8Z1JFZbZ8AQDSv
Oq0An3AIfm+JehVVhZksgxmwNfhWi0Sd
=0qyh
-----END PGP SIGNATURE-----
 
Old 04-04-2011, 11:48 AM
Brian Harring
 
Default 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 <python@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
 
Old 04-04-2011, 04:02 PM
Alec Warner
 
Default python-namespaces.eclass

2011/4/4 Tomáš Chvátal <scarabeus@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/
>
> iEYEARECAAYFAk2Zl7wACgkQHB6c3gNBRYeH9wCfcac24FDG2t 8Z1JFZbZ8AQDSv
> Oq0An3AIfm+JehVVhZksgxmwNfhWi0Sd
> =0qyh
> -----END PGP SIGNATURE-----
>
>
 
Old 04-04-2011, 05:43 PM
Arfrever Frehtes Taifersar Arahesis
 
Default 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
 
Old 04-04-2011, 06:01 PM
Arfrever Frehtes Taifersar Arahesis
 
Default 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
 
Old 04-05-2011, 04:33 AM
Jeroen Roovers
 
Default python-namespaces.eclass

On Mon, 4 Apr 2011 01:13:37 +0200
Arfrever Frehtes Taifersar Arahesis <Arfrever@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
 
Old 04-30-2011, 09:27 PM
Arfrever Frehtes Taifersar Arahesis
 
Default python-namespaces.eclass

2011-04-04 13:48:43 Brian Harring napisał(a):
> > # @ECLASS: python-namespaces.eclass
> > # @MAINTAINER:
> > # Gentoo Python Project <python@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.

IMHO it's sufficient, but could you suggest some sentences of description?

--
Arfrever Frehtes Taifersar Arahesis
 
Old 04-30-2011, 10:32 PM
Brian Harring
 
Default python-namespaces.eclass

On Sat, Apr 30, 2011 at 11:27:47PM +0200, Arfrever Frehtes Taifersar Arahesis wrote:
> 2011-04-04 13:48:43 Brian Harring napisał(a):
> > > # @ECLASS: python-namespaces.eclass
> > > # @MAINTAINER:
> > > # Gentoo Python Project <python@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.
>
> IMHO it's sufficient, but could you suggest some sentences of description?

It probably is sufficient for *you*- you're knee deep in the guts of
python, and know it's purpose. Plus you wrote the eclass

The purpose of the description, and general code comments is for
*other* folk who may be looking at that code/problem for the first
time. It needs to be written aimed at them.

I'd suggest doing a grep of DESCRIPTION w/in eclasses and working from
the clearer examples- just looking at the first few examples returned,
alternatives for example has enough in the opening description to
understand exactly what it's for, same for apache-2.

One thing to keep in mind is that even for folk who know python, this
is actually an area that doesn't match the normal verbage, and is a
bit niche in it's usage- try googling 'python namespaces' sometime,
note that it's scope discussions rather than pkgutil/distribute
importation across multiple directories.

To be clear, 'python namespaces' is a whole other thing from what this
is doing- this is manipulation of importation pathways (the
module/import hierarchy/namespace, rather than the common scope
terminology).

Either way, rough suggestion:
"""
This eclass handles installation/creation of python 2.7 and higher
pkgutil namespaces, and the equivalent distibute functionality. See
zope's (example ebuild) for examples of usage.
"""

Rewording it might be wise, but that lays out exactly what this is
for, it's intended usage, and gives folks a pointer were to look for
usage examples.
~brian
 
Old 04-30-2011, 10:49 PM
Arfrever Frehtes Taifersar Arahesis
 
Default python-namespaces.eclass

2011-05-01 00:32:13 Brian Harring napisał(a):
> On Sat, Apr 30, 2011 at 11:27:47PM +0200, Arfrever Frehtes Taifersar Arahesis wrote:
> > 2011-04-04 13:48:43 Brian Harring napisał(a):
> > > > # @ECLASS: python-namespaces.eclass
> > > > # @MAINTAINER:
> > > > # Gentoo Python Project <python@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.
> >
> > IMHO it's sufficient, but could you suggest some sentences of description?
>
> It probably is sufficient for *you*- you're knee deep in the guts of
> python, and know it's purpose. Plus you wrote the eclass
>
> The purpose of the description, and general code comments is for
> *other* folk who may be looking at that code/problem for the first
> time. It needs to be written aimed at them.
>
> I'd suggest doing a grep of DESCRIPTION w/in eclasses and working from
> the clearer examples- just looking at the first few examples returned,
> alternatives for example has enough in the opening description to
> understand exactly what it's for, same for apache-2.
>
> One thing to keep in mind is that even for folk who know python, this
> is actually an area that doesn't match the normal verbage, and is a
> bit niche in it's usage- try googling 'python namespaces' sometime,
> note that it's scope discussions rather than pkgutil/distribute
> importation across multiple directories.
>
> To be clear, 'python namespaces' is a whole other thing from what this
> is doing- this is manipulation of importation pathways (the
> module/import hierarchy/namespace, rather than the common scope
> terminology).
>
> Either way, rough suggestion:
> """
> This eclass handles installation/creation of python 2.7 and higher

__init__.py files generated by this eclass work with Python 2.4.
(I haven't tested them with older versions.)

> pkgutil namespaces, and the equivalent distibute functionality. See
> zope's (example ebuild) for examples of usage.
> """

--
Arfrever Frehtes Taifersar Arahesis
 

Thread Tools




All times are GMT. The time now is 05:04 PM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org