[lldb-dev] new 'import' script by path command

[Johnny Chen]

Hi Enrico,

I'm not sure whether the TestImport.py test case belongs under test/python_api at all?
Anyway, you should not make the test case skipUnless it's a Darwin platform.

I shall check in the examples patch for the time being, since the test patch and the examples/customization/import-python
patch are a little bit redundant?  What do you think?

Thanks.

On Oct 12, 2011, at 1:08 PM, Enrico Granata wrote:

> Hello,
> 
>> On Oct 12, 2011, at 8:00 PM, Johnny Chen wrote:
>> I checked in the cleanup patch for TestCommanPython.py.
>> As for the 'import' command, can you rework the patch to rely on os.sep instead of '/'
>> as the pathname components separator?
>> 
>> Thanks.
> 
> 
> <importcmd.diff>
> 
> Attached is an updated patch file which uses os.sep as suggested, and uses the new examples/customization directory to store the example import command (plus a README). If you feel any more changes are required before this is ready for commit, let me know.
> 
>> On Oct 12, 2011, at 8:11 PM, Jim Ingham wrote:
>> 
>> This is a nice convenience, I was a little worried at first because I want to try to avoid introducing top-level name commands when not necessary...  I want to keep that namespace as clean as possible so people can use it for shortcuts. 
>> 
>> On thinking a bit, it seems more logical to me if the same functionality was done through "command script import"; that could do whatever the current script language does to import a module into the scripting language.
>> 
>> It is also pretty consistent with having "command script add/delete/etc..."
>> 
>> If you follow this through further, if we have control of it we could also make some convention like if you do:
>> 
>> def __lldb_init_for_interpreter (lldb_interpreter):
>> 
>> we would call this and pass in the LLDB interpreter that was doing the import.  Then you could put your package's "command script add" commands in there.  That way you could make up modules that you import and they would add all their commands to the LLDB interpreter they were being imported into...
>> 
> 
> My personal preference would be to pass the SBDebugger instead. From the SBDebugger one can go to the associated SBCommandInterpreter, but doing the reverse is not possible as far as I can tell. Is there anything sensible that one could do with the Debugger in this scenario other than just grab the SBCommandInterpreter and run a few "command script add" commands? While I cannot think about any obvious example, having access to the list of targets seems valuable..
> 
>> We could also add commands to set the PYTHONPATH, etc, like:
>> 
>> command script import --path-component ~/.lldb_python my_script...
> 
> Would this command read like "import a file named my_script.py from a folder name ~/.lldb_python?" I was thinking about something like
> command script import ~/myfile.py which would automatically check whether ~ is in sys.path and if not append it, and then import myfile
> Most probably, it makes sense to delegate this to the ScriptInterpreterPython for actual implementation, and if LLDB script language is set to anything different, just reject the command "sorry, do not know how to import for your current script language" (much like we do for command script add currently)
> 
>> 
>> This is more work, so I have no problem with adding the example for now.  But if we do more work on it, I argue more for it's going into "command script import..."
>> 
> 
> I would go for adding the example script for the time being. I can definitely work on "command script import", but it is going to take a few days, so I guess having the Pythonic example there won't hurt. Once I get to implementing the new command, I will also rework the test case to test that one instead of the script.
> I will keep you up to date on progress there. As usual, if you have any feedback or suggestions, let me know.
> 
>> Jim
> 
> 
> - Enrico

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/lldb-dev/attachments/20111012/13e5e8f1/attachment.html>