Closed psalaberria002 closed 1 week ago
We typically use the venv that gets created here for IDE support and/or local interactive testing, in both cases the repository root is available. I'm open to supporting some customization when the venv is produced, but, before we start with approaches, could you talk more about how you plan to use the produced virtual environment?
We have python modules in lib/python which we don't want to import as lib.python.
The reason for this is easier wheel publishing, and cleaner import paths.
I am sure there may be other scenarios where site customize or pth files can be useful.
We only use the venv for local development and IDEs.
Got it ... and just to double check you'd configure the set of paths you want on the create_venv
target?
Got it ... and just to double check you'd configure the set of paths you want on the
create_venv
target?
Yes, it would be linked to the target. Currently I have a patch which adds a sitecustomize.py that I provide to create_venv to site packages. It's more flexible than adding custom .pth files. But to be honest using pth files would be sufficient.
I don't feel strongly -- a simple thing here would be giving you a data
arg that lets you include an arbitrary set of extra labels, would be happy to review a PR if that suits your needs?
By the way, the repo root isn't added to the pythonpath unless you run the python commands from the root. If you want to be able to run python commands from a subfolder then you need to either manually update PYTHONPATH, or use .pth or sitecustomize.
In order to add the repository root, or other paths of the repo, to the Python path inside the venv we have various options.
We can of course set PYTHONPATH env var, but this is a manual step.
Inside a virtual environment we can leverage either sitecustomize.py or .pth files instead, and automate the process. It is as simple as copying the files to
$site_packages_dir"
.Any thoughts or preferences on how to implement this?