virtualenv-workon mangles exec-path entry
Bug #1050127 reported by
Vinod
This bug affects 1 person
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
python-mode.el |
Fix Released
|
Medium
|
Andreas Roehler |
Bug Description
python-mode version: 6.0.10
I have a virtualenv named 'env0' in the directory '/home/
Code:
(virtualenv-workon "env0")
(car exec-path) ; returns "/home/
There should be a slash between env0 and bin. The easy answer is to add a slash in virtualenv-workon, but it might also be useful to test that the path is valid (using the function virtualenvp)
Changed in python-mode: | |
milestone: | none → 6.1.1 |
assignee: | nobody → Andreas Roehler (a-roehler) |
importance: | Undecided → Medium |
Changed in python-mode: | |
status: | Fix Committed → New |
Changed in python-mode: | |
status: | Fix Committed → Fix Released |
To post a comment you must log in.
from emacs-devel, just to keep that note at the matter
Am 13.10.2012 21:41, schrieb Fabian Ezequiel Gallina:> 2012/10/13 David Engster <email address hidden>: to-string? shell-internal- send-string "import sys;print ('\x00' .join(sys. path))" )
>> Andreas Röhler writes:
>>> Am 13.10.2012 14:26, schrieb David Engster:
>>>> Andreas Schwab writes:
>>>>> David Engster <email address hidden> writes:
>>>>>
>>>
>>>>>> So here's my question: What is The Right Way to send and parse the
>>>>>> command above?
>>>>>
>>>>> How about shell-command-
>>>>
>>>> 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-
>
> 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
>