I use venv module to make a virtual environment in cpython3.6.
After it, I try to activate it with fish, but it give me an error, like the screenshot.
I open the activate.fish and remove the $ sign in line 58 and 59, then the activate file works.
I open the activate.fish of py3.5 venv, there isn't a $ sign in line 58 and 59, too.
However, there is a bug issue which add the $ in front of the prompt.
I'm not sure how this happen, but I think there should not be a $ there.

The change you mention was in response to Issue bpo-26348. The patch supplied there introduced the $ characters you say aren't required. I'm not a fish user, but it would seem that "$VENV_PROMPT" would resolve to the *value* of the environment variable __VENV_PROMPT__, whereas "__VENV_PROMPT__" would just resolve to the literal string "__VENV_PROMPT__" which doesn't seem like what is wanted. Can you explain the reasoning by which you assert that the $ isn't wanted?

First, I use python 3.5.1 to create virtual environment. It works fine with fish. There is no $ in the activate.fish file.
Second, after I removed the $, It works fine, both in ubuntu and arch linux.

I guess it is because the $ is for bash not for fish, the activate.fish didn't work.
These are why I assert the $ is unwanted.

I've asked the person who sent in the patch for bpo-26348 to comment on this issue.

I'm getting this exact issue on Python 3.5 (xenial system installation).

All my existing venvs (from before my upgrade to xenial) work. Here's the diff:

diff .venv/bin/activate.fish ../wrapt/.venv/bin/activate.fish
35c35
< set -gx VIRTUAL_ENV "/home/tin/pg/hypothesis/.venv"
---
set -gx VIRTUAL_ENV "/home/tin/pg/wrapt/.venv"
58,59c58,59
< if test -n "$(.venv) "
< printf "%s%s%s" "$(.venv) " (set_color normal) (_old_fish_prompt)
---
if test -n "(.venv) "
printf "%s%s%s" "(.venv) " (set_color normal) (_old_fish_prompt)

The added dollar signs are the issue. Removing them fixes the problem.

For the record:

fish --version
fish, version 2.2.0

And here's the actual error message, the same as in the png:

. .venv/bin/activate.fish
$(...) is not supported. In fish, please use '(.venv)'.
.venv/bin/activate.fish (line 58): if test -n "$(.venv) "
^
from sourcing file .venv/bin/activate.fish
called on line 151 of file /usr/share/fish/config.fish

in function “.”
called on standard input

source: Error while reading file “.venv/bin/activate.fish”

Also I will add I've been using fish for a long time and have never been affected by bpo-26348.

The patch introduced by bpo-26348 should be reverted. The __VENV_PROMPT__ is meant to be a placeholder. For example, when you create a virtual environment named venv-test, the __VENV_PROPMT__ will be replace by (venv-test). If the patch is applied, it will be $(venv-test), treated as an expression and then cause a failure.

This bug shipped in 3.5.2. It should've been a blocker.

I get the same feeling. Add Larry.

New changeset 8d7bde14d7a4 by Brett Cannon in branch 'default':
Merge from 3.5 for issue bpo-26664
https://hg.python.org/cpython/rev/8d7bde14d7a4

Two things.

One, sorry for not getting to this before 3.5.1 got out. It simply slipped off my radar thanks to various other issues that I've been dealing with. It's obviously now fixed.

Two, this is not a release blocker. Python itself continues to function properly with this bug and it doesn't prevent you from working with a venv under fish (but I recognize it's an annoyance).

Two, this is not a release blocker. Python itself continues to function properly with this bug and it doesn't prevent you from working with a venv under fish (but I recognize it's an annoyance).

If you can't load the venv, I think that pretty definitely prevents you from working with one. I'll now have to edit the activation script file manually every time I create a new venv until 3.6 is released. Or revert to 3.5.1.

Activation doesn't "load" the Python interpreter in the venv; all it does is tweak shell variables to put the interpreter in venv early on PATH. I personally never use the activate.* scripts and simply directly execute the Python interpreter, e.g. venv/bin/python. The only other thing the activation script does that potentially changes semantics is the setting of $PYTHONHOME which can do manually if you need that specific bit of functionality.

You have to realize that there are over 5,000 issues open on bugs.python.org. We are all volunteers working on Python and we do our best to get through issues, but we just don't get to everything on the timeframe people prefer. I realize this issue is important to you, but basically every reported issue is important to someone so every time we prioritize anything over something else we are upsetting someone somewhere.

Thanks for dealing with this, Brett, your efforts are appreciated. :)

On Thu, Jun 30, 2016 at 9:24 PM Brett Cannon <report@bugs.python.org> wrote:

Brett Cannon added the comment:

Activation doesn't "load" the Python interpreter in the venv; all it does
is tweak shell variables to put the interpreter in venv early on PATH. I
personally never use the activate.* scripts and simply directly execute the
Python interpreter, e.g. venv/bin/python. The only other thing the
activation script does that potentially changes semantics is the setting of
$PYTHONHOME which can do manually if you need that specific bit of
functionality.

You have to realize that there are over 5,000 issues open on
bugs.python.org. We are all volunteers working on Python and we do our
best to get through issues, but we just don't get to everything on the
timeframe people prefer. I realize this issue is important to you, but
basically every reported issue is important to someone so every time we
prioritize anything over something else we are upsetting someone somewhere.

----------

---

Python tracker <report@bugs.python.org>
<http://bugs.python.org/issue26664\>

---

Activation doesn't "load" the Python interpreter in the venv; all it does is tweak shell variables to put the interpreter in venv early on PATH.

I'm aware.

You have to realize that ...

I know it's often a thankless task and that mistakes can and do happen. Not prioritising a two-click fix to a regression that was spotted several months in advance would - in my book - count as such a mistake. Okay, you were preoccupied with other things - that's fine. That's a valid excuse. And if you disagree with the importance of it, that's also fine; I'm not gonna argue my case further.

I wish it was a two-click fix. It's actually a fix-in-3.5-then-test-then-update-Misc/NEWS-then-commit-then-merge-then-verify-again-then-commit-then-push-then-update-the-issue (IOW it's about 8 separate steps).

Since the bug is fixed, we can also close bpo-26348.

+1 here, broken on homebrew cpython > 3.5.1 (a.k.a. 3.5.2)