$ pyvenv-3.3 env
$

It could tell me that I need to go into the directory and type "source bin/activate" (this is probably platform-dependent :-)).

It should produce any output. Command line utilities typically don't provide a success report. Would you want "mkdir env" to say "created env directory; you can now cd into it", or "cat /etc/passwd" append "successfully displayed text file"???

There are exceptions, of course, such as make(1). They may be reasonable in cases where the user might not be certain what constitutes a successful operation. In this case, it's fairly clear what you wanted to happen. In case you don't know in detail what is in the venv, you can look for yourself.

Whether "source activate" is good advise or not, I'm not so sure - I'd typically run  env/bin/python instead.

> Command line utilities typically don't provide a success report.

It depends which ones. Even Mercurial doesn't always abide by that rule (e.g. "hg clone" will tell you that it updates to the default branch).

> Whether "source activate" is good advise or not, I'm not so sure - I'd 
> typically run  env/bin/python instead.

That's good if you only want to use the interpreter directly, but not if you want to call any scripts.

Also, the reason I think "source activate" is good advice is that it's easy to type instead "./bin/activate" which silently succeeds (but is actually a no-op, from the caller's point of view).

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. As well as running the venv's Python, any script in the venv should be immediately invokable (and call up the venv's interpreter). At the moment, that's just pydoc - but that might change over time (I originally had pysetup in there, before packaging got pulled).

AFAIK the activate script shouldn't have the executable bit set, so it shouldn't show up in e.g. autocomplete results. 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.

It's assumed that third party tools will build on top of the existing venv support - for example, in the absence of packaging, venvs will need distribute/pip in order for users to be able to install stuff into them. 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).

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

> Well, having to run "source bin/activate" is not obvious (unless you've
> already used virtualenv)

Using venv is not obvious in the first place. so presumably, the user has
read some documentation telling him what it is and how it's used. Presumably,
that documentation then mentions the activate script (with pros and cons).

I remain -1 on printing anything by default.

> > Well, having to run "source bin/activate" is not obvious (unless you've
> > already used virtualenv)
> 
> Using venv is not obvious in the first place.

Well, why couldn't it *become* obvious. It's not supposed to be a
complicated piece of software. It does one single thing and it has only
a handful of options (one of which is a no-op :-)).

>> Using venv is not obvious in the first place.
>
> Well, why couldn't it *become* obvious.

Because the notion of a "virtual environment" is inherently
non-obvious. Is it like a virtual machine (and if so, like
VMWare or like Java, both with virtual machines - doesn't
Python have a virtual machine already)? Is it like a virtual
host in Apache? I asked people, and even after explaining what
it is, it was not clear to them what it is good for. You really
need to have the problem that it solves, or else you can't
comprehend what it does. Please trust me on that.

> It does one single thing and it has only a handful of options
> (one of which is a no-op :-)).

Perhaps it's a no-op only on your preferred operating system - that doesn't mean it's a no-op for everyone :-)

I don't mind clarifying/expanding the help output, but I also feel there's no need to print anything by default when a venv is created.

New changeset 9c345b4bd97e by Vinay Sajip in branch 'default':
Closes #15281, #15283: Don't make venv scripts executable, but copy source mode instead, and provide better help for pyvenv.
http://hg.python.org/cpython/rev/9c345b4bd97e

> Creating a venv is useless if you don't ever activate it, right.
This is a common misconception.  Shell activation is only about putting the venv’s bin directory on the beginning of the PATH.  It’s a purely optional convenience.  Using a virtualenv can be done fully with explicit paths like Martin mentioned.

I think, the ``source bin/activate`` should be mentioned in the Docs
at least. It should not require that a person carries this knowledge
from somewhere else. At the moment, I do not see mention of it in the
docs either -

http://docs.python.org/dev/library/venv.html

New changeset baf5ed391a7f by Vinay Sajip in branch 'default':
Issue #15283: Updated pyvenv documentation to expand on activation.
http://hg.python.org/cpython/rev/baf5ed391a7f