From: Richard Purdie <richard.purdie@linuxfoundation.org>
To: Martin Jansa <martin.jansa@gmail.com>
Cc: bitbake-devel <bitbake-devel@lists.openembedded.org>,
openembedded-core <openembedded-core@lists.openembedded.org>
Subject: Re: [bitbake-devel] PLEASE READ: Major change landing shortly (python whitespace)
Date: Wed, 18 Jul 2012 14:11:14 +0100 [thread overview]
Message-ID: <1342617074.30680.26.camel@ted> (raw)
In-Reply-To: <20120718104012.GJ22569@jama.jama.net>
On Wed, 2012-07-18 at 12:40 +0200, Martin Jansa wrote:
> On Wed, Jul 18, 2012 at 11:06:45AM +0100, Richard Purdie wrote:
> > It's become clear we have a horrible mixture of whitespace (tabs and
> > space) in python functions. At first glance this sounds trivial but
> > there is a serious problem if pieces of code get mixed together with
> > different whitespace since they may or may not work as intended.
> >
> > The documented standard for python functions is four space indentation
> > although we have a mixture. Fixing this sounds simple at first, we just
> > go through and change tabs to spaces. The problem comes with _append and
> > _prepend to python functions since both need their whitespace changed at
> > the same time. populate_packages() is the real problem child in that
> > regard but its the less common examples I worry about.
> >
> > I did some research and we have inconsistencies, even in existing
> > functions since people are editing files and getting confused
> > (understandably).
> >
> > So the question becomes, how do we get ourselves out of this mess?
> >
> > I put a proposal to the TSC, that we have bitbake warn/error whenever it
> > finds tab characters in any python function. The advantage of this is
> > that we give the user a clear definitive error. The downside is that
> > we'll have to go through all the metadata and scrub it for the problem.
> >
> > The TSC agrees we should do something about this rather than perpetuate
> > the problem and that this is as good a solution as any of us can come up
> > with. We also agreed that we should do it sooner than later before it
> > gets any later in this release cycle. Putting it off until the next
> > release cycle didn't seem to offer any advantage, we might as well get
> > on with it.
> >
> > So I am going to:
> >
> > a) Try and flush through as many pending patches as I can.
> > b) Check in a warning into bitbake master and increase its version
> > c) Require that version in OE-Core
>
> Great.. this is usefull also for latest change from proto to protocol
> param in fetcher, but please make sure that the svn.py patch I've sent
> yesterday is also in before release..
I was aware of this issue too which was at the back of my mind when I
proposed this. The svn patch is in now.
Cheers,
Richard
next prev parent reply other threads:[~2012-07-18 13:22 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-07-18 10:06 PLEASE READ: Major change landing shortly (python whitespace) Richard Purdie
2012-07-18 10:17 ` Burton, Ross
2012-07-18 11:40 ` Richard Purdie
2012-07-18 21:43 ` [bitbake-devel] " Martin Jansa
2012-07-19 8:26 ` Henning Heinold
2012-07-19 9:49 ` Martin Jansa
2012-07-19 10:15 ` Richard Purdie
2012-07-19 11:18 ` Martin Jansa
2012-07-19 11:27 ` Martin Jansa
2012-07-18 10:40 ` Martin Jansa
2012-07-18 13:11 ` Richard Purdie [this message]
2012-07-19 14:44 ` Jack Mitchell
2012-07-19 15:23 ` Martin Jansa
2012-07-20 9:38 ` Jack Mitchell
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1342617074.30680.26.camel@ted \
--to=richard.purdie@linuxfoundation.org \
--cc=bitbake-devel@lists.openembedded.org \
--cc=martin.jansa@gmail.com \
--cc=openembedded-core@lists.openembedded.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox