Re: Question about python interpreter in methods embedded in recipes

[Richard Purdie <richard.purdie@linuxfoundation.org>]

On Wed, 2015-08-12 at 11:23 +0200, Rémi Peuvergne wrote:
> I've been investigating on an issue when building an image, and I gave
> up doing what I first wanted.
> I'd like to know more about the issue, and possibly suggest an
> improvement to bitbake...
>
> The issue is related to "embedded python methods" in recipes.
>
> In my image recipe, I'm modifying the rootfs (basically to add a
> hashed password to /etc/shadow), with something like :
>
> python set_password() {
> <some piece of python script here>
> }
>
> The thing is, this piece of code is executed by the *host*
> interpreter, so it depends on the dev machine (in my case I ran into
> an issue with crypt.mksalt() not being available).
> It would be nice to allow executing this with the *native*
> interpreter, the one built during the whole image build process.
>
> I tried inheriting pythonnative, which sets the PYTHON variable the
> correct way, but it's not used for those methods...
> I guess it's not easy, since it would need to pass the datastore, but
> I wonder if there's any smart solution to this ?

The system is only setup such that we run the host interpreter. We don't
know when the native python version would become available (or even if
it would get built) and even if we did, we'd then have to switch
interpreters half way through execution.

Such an approach would add a lot of complexity for not a lot of gain. If
you really need pythonnative, you could execute a separate script using
it?

Cheers,

Richard