All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Aníbal Limón" <anibal.limon@linux.intel.com>
To: Randy Witt <randy.e.witt@linux.intel.com>,
	"Burton, Ross" <ross.burton@intel.com>
Cc: "Paul Eggleton" <paul.eggleton@linux.intel.com>,
	"Aníbal Limón" <limon.anibal@gmail.com>,
	OE-core <openembedded-core@lists.openembedded.org>
Subject: Re: [PATCH 2/4] classes/testsdk: Move the removal of bitbake PATH to eSDK context only
Date: Mon, 22 Feb 2016 11:47:30 -0600	[thread overview]
Message-ID: <56CB49B2.5040306@linux.intel.com> (raw)
In-Reply-To: <56CB44EA.5000303@linux.intel.com>

[-- Attachment #1: Type: text/plain, Size: 2206 bytes --]



On 02/22/2016 11:27 AM, Randy Witt wrote:
> On 02/22/2016 09:05 AM, Aníbal Limón wrote:
>>
>>
>> On 02/22/2016 10:48 AM, Burton, Ross wrote:
>>> On 22 February 2016 at 16:37, Aníbal Limón
>>> <anibal.limon@linux.intel.com>
>>> wrote:
>>>
>>>> I agree with you to modify avoid_paths_in_environ for return the new
>>>> PATH variable is better than only modify it internally but for
>>>> simplicity i will maintain the os.environ['PATH'] set/restore
>>>> instead of
>>>> generate the environment line.
>>>>
>>>
>>> Totally agree with Randy here for what it's worth.  The
>>> environment-munging
>>> code in avoid_paths... should return the strings instead of manipulating
>>> the current environment so the caller has the choice whether to
>>> modify the
>>> current environment or pass a new environment to subprocess.  And in
>>> general I'd say that passing modified environments to subprocess is a
>>> cleaner solution as it means that there's no way cleanup can fail to
>>> happen.  Whilst that's just a try/except now, the code could get
>>> copied and
>>> extended and end up with codepaths that don't hit the right cleanup.  By
>>> having an explicit environment passed in, this isn't possible.
>>
>> Agree, now modified at,
>>
>> http://git.yoctoproject.org/cgit/cgit.cgi/poky-contrib/commit/?h=alimon/esdk_update_v2&id=3143bf09130c52cd71e3f2f9795208e17152005d
>>
> 
> If you either convert path to a dict or have avoid_paths_in_environ()
> return a dict you can do:
> 
> +            output = subprocess.check_output(". %s > /dev/null; %s;" % \
> +                (self.tc.sdkenv, cmd), env=path, shell=True)
> 
> It's not quite obvious in the docs that you can pass that in, they refer
> you to the Popen docs.


I know that you could pass env in kwargs but since it's using shell=True
is easy to set PATH inline also it causes a little overhead for copy the
os.environ.

But if you want the another way that's ok, see [1].

[1]
http://git.yoctoproject.org/cgit/cgit.cgi/poky-contrib/commit/?h=alimon/esdk_update_v2&id=ab84d325c5cbb751d7b18e861964b757d9682e0f

	alimon

> 
>> Cheers,
>>     alimon
>>
>>>
>>> Ross
>>>
>>
> 


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

  reply	other threads:[~2016-02-22 17:45 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-02-22 15:03 [PATCH 0/4] Add extensible SDK update test Aníbal Limón
2016-02-22 15:03 ` [PATCH 1/4] classes/testsdk: Move code for avoid PATHs to oeqa.utils Aníbal Limón
2016-02-22 15:03 ` [PATCH 2/4] classes/testsdk: Move the removal of bitbake PATH to eSDK context only Aníbal Limón
2016-02-22 15:54   ` Randy Witt
2016-02-22 16:09     ` Aníbal Limón
2016-02-22 16:23       ` Randy Witt
2016-02-22 16:37         ` Aníbal Limón
2016-02-22 16:48           ` Burton, Ross
2016-02-22 17:05             ` Aníbal Limón
2016-02-22 17:27               ` Randy Witt
2016-02-22 17:47                 ` Aníbal Limón [this message]
2016-02-22 18:04                   ` Aníbal Limón
2016-02-22 15:03 ` [PATCH 3/4] classes/testsdk: Pass tcname to SDK and SDKExt contexts Aníbal Limón
2016-02-22 15:03 ` [PATCH 4/4] oeqa/sdkext: Add sdk_update.SDKUpdateTest class Aníbal Limón
2016-02-22 16:18   ` Randy Witt
2016-02-22 16:26     ` Aníbal Limón
2016-02-22 16:36       ` Randy Witt
2016-02-22 17:10         ` Aníbal Limón

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=56CB49B2.5040306@linux.intel.com \
    --to=anibal.limon@linux.intel.com \
    --cc=limon.anibal@gmail.com \
    --cc=openembedded-core@lists.openembedded.org \
    --cc=paul.eggleton@linux.intel.com \
    --cc=randy.e.witt@linux.intel.com \
    --cc=ross.burton@intel.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.