all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
* Getting Python system paths for CEDET
@ 2012-10-13  9:28 David Engster
  2012-10-13 12:14 ` Andreas Schwab
  2012-10-13 12:41 ` Andreas Röhler
  0 siblings, 2 replies; 8+ messages in thread
From: David Engster @ 2012-10-13  9:28 UTC (permalink / raw)
  To: emacs-devel; +Cc: Fabián E. Gallina, jan.moringen

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



^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: Getting Python system paths for CEDET
  2012-10-13  9:28 Getting Python system paths for CEDET David Engster
@ 2012-10-13 12:14 ` Andreas Schwab
  2012-10-13 12:26   ` David Engster
  2012-10-13 12:41 ` Andreas Röhler
  1 sibling, 1 reply; 8+ messages in thread
From: Andreas Schwab @ 2012-10-13 12:14 UTC (permalink / raw)
  To: emacs-devel; +Cc: Fabián E. Gallina, jan.moringen

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."



^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: Getting Python system paths for CEDET
  2012-10-13 12:14 ` Andreas Schwab
@ 2012-10-13 12:26   ` David Engster
  2012-10-13 15:13     ` Andreas Röhler
  0 siblings, 1 reply; 8+ messages in thread
From: David Engster @ 2012-10-13 12:26 UTC (permalink / raw)
  To: Andreas Schwab; +Cc: Fabián E. Gallina, emacs-devel

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



^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: Getting Python system paths for CEDET
  2012-10-13  9:28 Getting Python system paths for CEDET David Engster
  2012-10-13 12:14 ` Andreas Schwab
@ 2012-10-13 12:41 ` Andreas Röhler
  1 sibling, 0 replies; 8+ messages in thread
From: Andreas Röhler @ 2012-10-13 12:41 UTC (permalink / raw)
  To: emacs-devel, David Engster, Barry Warsaw

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










^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: Getting Python system paths for CEDET
  2012-10-13 12:26   ` David Engster
@ 2012-10-13 15:13     ` Andreas Röhler
  2012-10-13 17:20       ` David Engster
  0 siblings, 1 reply; 8+ messages in thread
From: Andreas Röhler @ 2012-10-13 15:13 UTC (permalink / raw)
  To: emacs-devel

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




^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: Getting Python system paths for CEDET
  2012-10-13 15:13     ` Andreas Röhler
@ 2012-10-13 17:20       ` David Engster
  2012-10-13 19:41         ` Fabian Ezequiel Gallina
  0 siblings, 1 reply; 8+ messages in thread
From: David Engster @ 2012-10-13 17:20 UTC (permalink / raw)
  To: Andreas Röhler; +Cc: emacs-devel

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



^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: Getting Python system paths for CEDET
  2012-10-13 17:20       ` David Engster
@ 2012-10-13 19:41         ` Fabian Ezequiel Gallina
  2012-10-13 20:32           ` David Engster
  0 siblings, 1 reply; 8+ messages in thread
From: Fabian Ezequiel Gallina @ 2012-10-13 19:41 UTC (permalink / raw)
  To: Andreas Röhler, emacs-devel

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



^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: Getting Python system paths for CEDET
  2012-10-13 19:41         ` Fabian Ezequiel Gallina
@ 2012-10-13 20:32           ` David Engster
  0 siblings, 0 replies; 8+ messages in thread
From: David Engster @ 2012-10-13 20:32 UTC (permalink / raw)
  To: Fabian Ezequiel Gallina; +Cc: Andreas Röhler, emacs-devel

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



^ permalink raw reply	[flat|nested] 8+ messages in thread

end of thread, other threads:[~2012-10-13 20:32 UTC | newest]

Thread overview: 8+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2012-10-13  9:28 Getting Python system paths for CEDET David Engster
2012-10-13 12:14 ` Andreas Schwab
2012-10-13 12:26   ` David Engster
2012-10-13 15:13     ` Andreas Röhler
2012-10-13 17:20       ` David Engster
2012-10-13 19:41         ` Fabian Ezequiel Gallina
2012-10-13 20:32           ` David Engster
2012-10-13 12:41 ` Andreas Röhler

Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/emacs.git
	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

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.