Can you be more specific about what startup you are talking about? .profile is executed when a user logs into a shell session. So maybe your “startup” is not a shell session. And a terminal is not a login shell.
And by the way: sourcing the venv automatically counterfeits the whole purpose of venvs. The main purpose is to isolate the runtime environment for specific programs, without changing the global runtime environment. It is a bit like securely locking the front door and keeping the back door wide open.
The Pi boots into the standard desktop. If I then open a terminal the venv is not active, but it is running as the pi user, and the line “source /home/pi/.venv/bin/activate” is in the pi .profile so I would expect it to be active. If I connect from desktop pc via ssh the venv is active.
under per-user environments it says “Instead of creating a virtual environment for each of your Python projects, you can create a single virtual environment for your user account. Activate that virtual environment before running any of your Python code. This approach can be more convenient for workflows that share many libraries across projects.” which is what I have done
This is a wrong assumption. As I wrote, .profile is only sourced for login-shells. A terminal is a program like any other program, so it rightfully ignores this (and many many other) files. Ssh is different: you log in to the target, so you have a login-shell and it sources .profile.
What you can do: check your shell:
echo $SHELL
and then add the lines to the shell initialization file. If the above command e.g. tells you that you are using the bash, then put the line into .bashrc.
The author obviously also did not understand the idea of virtual environments and why they were introduced.
Just to be fair: you can get away with this, but it is just not necessary to go through the hassle of a venv if you just use a single global one. In this case you could just use the single global runtime of Python.
Take this example: program A need library Foo in version 2.1 and installs it globally. Then you install program B that needs Foo in version 1.9 and it installs it globally. Chances are high that program A will fail thereafter. The same will happen if you use a single venv. The reason why it (sometimes) works is that installers are usually smart enough not to downgrade libraries. But it only works if Foo-2.1 did not introduce an incompatible change.
So my advice is: be aware of what you are doing. In a test/development environment you might save some time with your approach, but you can also shoot yourself into your foot and waste your time later hunting for spurios problems. In a production environment you most certainly don’t want a global venv.