Getting Python system paths for CEDET

Getting Python system paths for CEDET

[David Engster]

CEDET's Python support has a function
`semantic-python-get-system-include-path' which calls Python to more or
less simply do

import sys
print(sys.path)

and parse the resulting output. This little thing however has caused so
much problems in the past that I'd like to settle this thing now once
and for all.

I'm currently trying to get rid of the warning messages when compiling
our Python support since we're using stuff like `python-proc',
`python-buffer', `python-preoutput-result' and so on. I now see in
Emacs' python.el that there are new variables
`python-shell-internal-buffer', but the doc-string says that they are
only there because of CEDET compatibility. So it seems we're doing
things the wrong way.

So here's my question: What is The Right Way to send and parse the
command above? It'd be great if this could be made compatible with
'python-mode', which apparently is another Python mode for Emacs people
are using. Also, it should run with no problems in batch-mode so that
our unit tests run (this was a problem in the past).

-David

Re: Getting Python system paths for CEDET

[Andreas Schwab]

David Engster <deng@randomsample.de> writes:

> So here's my question: What is The Right Way to send and parse the
> command above?

How about shell-command-to-string?

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: Getting Python system paths for CEDET

[David Engster]

Andreas Schwab writes:
> David Engster <deng@randomsample.de> writes:
>
>> So here's my question: What is The Right Way to send and parse the
>> command above?
>
> How about shell-command-to-string?

That's what I thought, too. But people told me that it is better to go
through the python-mode layer, so that its configuration settings can be
reused (the Python version to use, for example).

-David

Re: Getting Python system paths for CEDET

[Andreas Röhler]

Am 13.10.2012 14:26, schrieb David Engster:
> Andreas Schwab writes:
>> David Engster <deng@randomsample.de> writes:
>>
>>> So here's my question: What is The Right Way to send and parse the
>>> command above?
>>
>> How about shell-command-to-string?
>
> That's what I thought, too. But people told me that it is better to go
> through the python-mode layer, so that its configuration settings can be
> reused (the Python version to use, for example).
>
> -David
>
>


(getenv "PYTHONPATH") should be all you need here.

However, it might not be of that great use for the Emacs side. When possible, let Python itself act.

HTH,

Andreas

Re: Getting Python system paths for CEDET

[David Engster]

Andreas Röhler writes:
> Am 13.10.2012 14:26, schrieb David Engster:
>> Andreas Schwab writes:
>>> David Engster <deng@randomsample.de> writes:
>>>
>
>>>> So here's my question: What is The Right Way to send and parse the
>>>> command above?
>>>
>>> How about shell-command-to-string?
>>
>> That's what I thought, too. But people told me that it is better to go
>> through the python-mode layer, so that its configuration settings can be
>> reused (the Python version to use, for example).
>
> (getenv "PYTHONPATH") should be all you need here.

Returns nil here, hence I don't get it. How does that help for seeing if
the user wants to use, say, "python2.7" or "python3.2"? If he already
configured that in the python mode he uses, he shouldn't have to do that
again for CEDET.

-David

Re: Getting Python system paths for CEDET

[Fabian Ezequiel Gallina]

2012/10/13 David Engster <deng@randomsample.de>:
> Andreas Röhler writes:
>> Am 13.10.2012 14:26, schrieb David Engster:
>>> Andreas Schwab writes:
>>>> David Engster <deng@randomsample.de> writes:
>>>>
>>
>>>>> So here's my question: What is The Right Way to send and parse the
>>>>> command above?
>>>>
>>>> How about shell-command-to-string?
>>>
>>> That's what I thought, too. But people told me that it is better to go
>>> through the python-mode layer, so that its configuration settings can be
>>> reused (the Python version to use, for example).
>>
>> (getenv "PYTHONPATH") should be all you need here.
>
> Returns nil here, hence I don't get it. How does that help for seeing if
> the user wants to use, say, "python2.7" or "python3.2"? If he already
> configured that in the python mode he uses, he shouldn't have to do that
> again for CEDET.
>
> -David
>

(python-shell-internal-send-string "import sys;print ('\x00'.join(sys.path))")

That will work on python 2 and 3 and will take into account virtualenv
settings the user may have set.

Regards,
Fabián E. Gallina

Re: Getting Python system paths for CEDET

[David Engster]

Fabian Ezequiel Gallina writes:
> (python-shell-internal-send-string "import sys;print ('\x00'.join(sys.path))")
>
> That will work on python 2 and 3 and will take into account virtualenv
> settings the user may have set.

Thanks, that's exactly what I was looking for. I will change our setup
code to use that function (if available, otherwise the old code will
have to do).

-David

Re: Getting Python system paths for CEDET

[Andreas Röhler]

Am 13.10.2012 11:28, schrieb David Engster:
> CEDET's Python support has a function
> `semantic-python-get-system-include-path' which calls Python to more or
> less simply do
>
> import sys
> print(sys.path)
>
> and parse the resulting output. This little thing however has caused so
> much problems in the past that I'd like to settle this thing now once
> and for all.
>
> I'm currently trying to get rid of the warning messages when compiling
> our Python support since we're using stuff like `python-proc',
> `python-buffer', `python-preoutput-result' and so on. I now see in
> Emacs' python.el that there are new variables
> `python-shell-internal-buffer', but the doc-string says that they are
> only there because of CEDET compatibility. So it seems we're doing
> things the wrong way.
>
> So here's my question: What is The Right Way to send and parse the
> command above? It'd be great if this could be made compatible with
> 'python-mode', which apparently is another Python mode for Emacs people
> are using. Also, it should run with no problems in batch-mode so that
> our unit tests run (this was a problem in the past).
>
> -David
>
>

Hi David,

AFAIU new python.el started as an extension of the shipped one, while not implementing all of the former.
Fortunately Fabian did choose different names, so it should not clash.

 From python-mode.el it should be sufficient not to unload python.el stuff, so CEDET might run.

Just to drop a note of interest so far,

Andreas

http://launchpad.net/python-mode