docs: add hint to add the src folder to the python path for virtual p…

[dennisrall]

I had some problems testing virtual projects, see #1086.
I added a hint on how to add the src folder to the python path with pytest.

[bluss]

When you say virtual, you don't mean the same thing as "rye init --virtual" I guess (from context), or am I wrong?

[bluss]

Maybe I am wrong and you mean that. But why does one have a "src" directory for a rye init --virtual project? That seems like a contradiction.

[dennisrall]

Yes I mean projects you get by running "rye init --virtual". But maybe then I am wrong about them. The docs about virtual Projects introduce them for just running python packages. Seems to me a bit like rye install? But the docker documentation copies the src folder from the virtual project to the Dockerfile.

So, do virtual projects contain code or not?

[bluss]

I would think of it like this - virtual projects are there if you want rye to manage a python environment (.venv) with a special list of packages (dependencies) without developing anything that looks like a python package ('similar' to those that are published to pip).

Code takes many shapes - probably there is code in a virtual project, but not necessarily. But if you want to have a python module that is imported from other scripts, that sounds like a python module that should be installed into the venv, like how it's done in a regular rye project (not virtual)

So if you feel a need to change PYTHONPATH, that sounds like you just want those python modules in the environment and a regular rye init --lib project seems like the right thing to use? With that said, I don't have any workflow that uses docker.

It's also possible to move the problem around. You have some code in src that you want to install into the current project's virtualenv. Either that code needs to be the library modules of the current project, or they need to be a dependency of the current project. So you could move it to a dependency (or workspace member).

[dennisrall]

I like the perspective of viewing the tests directory as a separated package where you want to install your package. I think then a normal package is better suited for this.