Setting this to "future" and adding Richard Purdie and Paul Eggleton to the CC list.

Richard to supply needed info

So I have been looking through devshell.bbclass (http://git.yoctoproject.org/cgit/cgit.cgi/poky/tree/meta/classes/devshell.bbclass) and in particular the devpyshell function.  This is my take on the function:

1. Sets it up so that there is no buffering or echo going on in the psuedo tty.
2. Forks a new process and if something goes wrong it bails at that point.
3. If the new process is forked okay, then all the stdin, stdout, etc stuff
   is set up.
4. Looks like some prompt strings are established
5. I am guessing that lines 105 through 141 is where the devshell is waiting 
   for input?  And, if there is a keyboard interrupt or there was a 
   SystemExit signal passed, they are handled.  

Since the purpose of devshell.bbclass is to add the do_devshell task (according to our docs), is it safe to say that the do_devpyshell task is what sets up the development shell and then does the job of catching input and all that?

I don't know... I don't read this code like you engineers.  So some extra clarification here would help me out. 

Thanks, 
Scott

Scott: I think it doesn't matter so much what the code does but more what the user can do with this. A "do_devpyshell" task is created that is similar to do_devshell but instead of bash, it drops you to an interactive python interpreter, in the same way that just running "python" at a shell prompt does.

In the devpyshell, key python objects and code are available in the same way they are to bitbake tasks, in particular, the data store 'd'. You can therefore do things like:

"bitbake bash -c devpyshell" and then in the shell window that opens:

pydevshell> d.getVar("STAGING_DIR", True)
'/media/build1/poky/build/tmp/sysroots'
pydevshell> d.getVar("STAGING_DIR", False)
'${TMPDIR}/sysroots'
pydevshell> d.setVar("FOO", "bar")
pydevshell> d.getVar("FOO", True)
'bar'
pydevshell> d.delVar("FOO")
pydevshell> d.getVar("FOO", True)
pydevshell> bb.build.exec_func("do_unpack", d)
pydevshell>

This would allow the user to inspect and work with the data store or execute functions.

So firstly, we document the existence of the task, secondly we give the user some examples of why this is useful and how it can be used.

Does that give you enough to put something basic in the manual about this?

Hi Richard, 

I can start with this.  It looks like we need a couple new sections in the YP doc set: one for a reference of the do_devpyshell task, and one in the dev-manual that talks about this interactive Python interpreter and what the user can do there. 

So, I have a new section here - http://www.yoctoproject.org/docs/2.2/dev-manual/dev-manual.html#platdev-appdev-devpyshell called "Using a Development Python Shell".  I started with the section just prior to it for using a development shell.  I have no idea how much of that stuff is the same for the Python version.  I am hoping you can review it and guide me.  

The other reference is here - http://www.yoctoproject.org/docs/2.2/ref-manual/ref-manual.html#ref-tasks-devpyshell.  It is brief and basically sends the reader off to the new section in the dev-manual. 

Thanks, 
Scott

"and you are placed in ${S}, the source directory" - that bit doesn't apply, nor does "In the new terminal, all the OpenEmbedded build-related environment variables are still defined so you can use commands such as configure and make". "For spawned terminals, the following occurs: " and the points underneath it are also not relevant, in fact you can just remove the rest of the section and notes and end it with "When you are finished using devpyshell, exit the shell using Ctrl+d or close the terminal window. ".

Otherwise looks good and at least means its documented in the manual. We can add more info if/as/when people have the time.

Thanks for the feedback Richard.  See http://www.yoctoproject.org/docs/2.2/dev-manual/dev-manual.html#platdev-appdev-devpyshell for the new section with the changes.  Let me know if there is anything further. 

Scott

Moving to 2.3 M2

We did get a review and no further issues... so setting to RESOLVED and putting the doc flag to "done."

Scott