> The reason it says nothing on success is that it follows the general
> philosophy of programs on Unix. Of course, there are exceptions, but
> it's not obvious that pyvenv should say anything, and what it should
> presume is the user's next likely step.

Well, having to run "source bin/activate" is not obvious (unless you've
already used virtualenv), so it's quite helpful to mention it. It's not
about being the next step, it's simply about informating the user.
Creating a venv is useless if you don't ever activate it, right.

If it's not in the pyvenv output, then perhaps it should be in the
"pyvenv --help" output. This way, users have an easy way to remind
themselves how to do. Having to context-switch to a browser and find the
module docs is too tedious.

> AFAIK the activate script shouldn't have the executable bit set, so it
> shouldn't show up in e.g. autocomplete results.

It does:

$ pyvenv-3.3 env
$ ls -la env/bin/activate 
-rwxr-xr-x 1 antoine antoine 2133 juil.  7 22:06 env/bin/activate*

> Note also that the activate script is bash-specific, so it may not be
> wise to mention it in cases where the user's shell may not be bash or
> a compatible shell.

Then the help output can be bash-specific too :)

> These will likely provide the visual feedback required (e.g. before
> merging into CPython, the pythonv version of pyvenv installed
> Distribute in the venv, which showed that something was happening).

Uh, I disagree with the idea that you should install something else to
make pyvenv useful. We should provide useful functionality out of the
box. Especially when doing so isn't particularly difficult or brittle.