All of lore.kernel.org
 help / color / mirror / Atom feed
From: Richard Purdie <richard.purdie@linuxfoundation.org>
To: Alexander Kanavin <alex.kanavin@gmail.com>,
	Joshua Watt <jpewhacker@gmail.com>
Cc: bitbake-devel@lists.openembedded.org
Subject: Re: [bitbake-devel][PATCH] cooker: Handle ImportError for websockets
Date: Tue, 25 Feb 2025 10:11:54 +0000	[thread overview]
Message-ID: <f81c98f506e531db8b119e5b30a091d10e916aed.camel@linuxfoundation.org> (raw)
In-Reply-To: <CANNYZj-G+j6yQXm0RCW5M2LcRxqVegsXuAPkLusO9+oueH2t=g@mail.gmail.com>

On Tue, 2025-02-25 at 09:22 +0100, Alexander Kanavin wrote:
> On Fri, 21 Feb 2025 at 17:07, Joshua Watt <jpewhacker@gmail.com>
> wrote:
> 
> > I agree the error message could be better, and also that buildtools
> > should not be on by default. Perhaps something as simple as:
> > 
> >    bitbake-setup --buildtools
> > 
> > could enable it automatically? I think if there is such a simple
> > option like that it will make it pretty easy for the end users to
> > do
> > the right thing.
> 
> How do I put this politely? Such an option is not simple or easy for
> the end users, and I'm strongly against this sort of 'solution'. The
> problem is that you, me, RP and everyone else here are suffering from
> 'yocto experience bias', and such suggestions come from that bias. We
> know what to do when we see an error that can be resolved by
> installing buildtools and putting them into PATH.

There is a tricky balancing act here as you also have to give users a
reasonable expectation.

We're not a point and click GUI where every possible choice is going to
work, in fact the more you deviate from the tested paths, the larger
the number of issues you're going to have to handle yourself.

I therefore worry that setting an expectation of everything working,
just means when something does fail, users are going to more
surprised/upset.

Hiding host contamination issues behind the scenes means you could end
up with a generation of patch submitters who simply don't
test/know/care about that set of problems and I'm not sure the project
would benefit from that in the long run.

So whilst I do see your point, we do have to draw a line somewhere and
I'm not convinced always using buildtools is the right one as a
default, particularly if we want every day developers using the tool
too (which we do).

I'd also note that buildtools isn't "free", it does have download time,
space use and installation time.

Cheers,

Richard



  reply	other threads:[~2025-02-25 10:12 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-05-02 18:35 [bitbake-devel][PATCH] cooker: Handle ImportError for websockets Joshua Watt
2025-02-20 16:05 ` Alexander Kanavin
2025-02-21  9:16   ` Richard Purdie
2025-02-21 16:07     ` Joshua Watt
2025-02-25  8:22       ` Alexander Kanavin
2025-02-25 10:11         ` Richard Purdie [this message]
2025-02-25 10:40           ` Alexander Kanavin
2025-02-25 10:52             ` Richard Purdie
2025-02-25 11:48               ` Alexander Kanavin
     [not found] ` <1825F6393BB749ED.25123@lists.openembedded.org>
2025-02-21  9:11   ` Alexander Kanavin
2025-02-21  9:14     ` Richard Purdie
2025-02-21 12:18       ` Alexander Kanavin

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=f81c98f506e531db8b119e5b30a091d10e916aed.camel@linuxfoundation.org \
    --to=richard.purdie@linuxfoundation.org \
    --cc=alex.kanavin@gmail.com \
    --cc=bitbake-devel@lists.openembedded.org \
    --cc=jpewhacker@gmail.com \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.