Open up TDPyEnvManagerContext.json

Super happy the inclusion of this feature and having a way of mounting environments during startup without having to rely on hacks.

The way it is currently setup is just very geared to the EnvManager and closes out the use of other tools.

I have a venv inside of my project folder called .venv
It is not possible for me to define the path to that env as the EnvManagerHelper as appending unrequested values to the pathing.
I tried the following configuration:

{
    "active": true,
    "mode": "Python vEnv",
    "envName": ".venv",
    "installPath": ".",
    "pythonVersion": "3.11",
    "pythonVersionNoDot": "311"
}

This results in the following output of the texport.

2025-10-09 15:00:00,568 - TDAppLogger.TDPyEnvManagerHelper - ERROR - Python executable not found at .venv_vEnv\Scripts\python.exe.

2025-10-09 15:00:00,570 - TDAppLogger.TDPyEnvManagerHelper - ERROR - Environment .venv_vEnv could not be linked. Context is: {'active': False, 'mode': 'Python vEnv', 'envName': '.venv', 'installPath': 'C:\\Users\\Wieland PlusPlusOne\\Documents\\GitHub\\PlusPlusOne\\TD_UvManagedPrefab', 'envPath': 'C:\\Users\\Wieland PlusPlusOne\\Documents\\GitHub\\PlusPlusOne\\TD_UvManagedPrefab\\.venv_vEnv', 'executablePath': 'C:\\Users\\Wieland PlusPlusOne\\Documents\\GitHub\\PlusPlusOne\\TD_UvManagedPrefab\\.venv_vEnv\\Scripts\\python.exe', 'osPath': [], 'sysPath': [], 'pythonVersion': '3.11', 'pythonVersionNoDot': '311'}
3.11.10 (heads/3.11-Derivative-dirty:e60cd070d8, Oct 10 2024, 15:55:11) [MSC v.1929 64 bit (AMD64)]

It append _venv to the given installpath without a way of changing this behaviour.


The second feature I would like to request is a way of adding an arbitrary number libs, as sometimes I also like to add other subsystems and be able to import them not being part of the specified environment.

My current setup uses a file like this to add arbitrary folder to the sys.path

# Lines starting with # will be ignored as comments.

# ${ gets converted in to ENV-Variable. }
${UV_PROJECT_ENVIRONMENT}/Lib/site-packages

project-packages
.venv/Lib/site-packages

Which works like a charm and allows for a pretty flexible and unopinionated way of adding site-packages.

@JetXS

Hi @plusplusone

Thanks for the feedback.

I will look into adding both features for more flexibility.

Best,
Michel

2 Likes

Hi Michel,
i was happy to see that docs now explicitlely spell out the _venv suffix for the env name, but the example file now will not work as in version 2025.31500 it seems to still append the _venv suffix.
This means it will try to mount "E:\\_DERIVATIVE\\Gitlab\\TDPyEnvManager\TDPyEnvManager_venv_venv"and I assume this is not intendet.

Maybe also some info on why I request the feature to addd arbitrary folders as additional site-packages:
When developing a component-package, for testing purposes I like to just add the src folder to sys.path so I can import the package directly. (Example: GitHub - PlusPlusOneGmbH/TauCeti: Presetsystem for touchdesigner)

Hi @plusplusone

They were no change related to those RFEs that made it to the current official.

What’s the example file you are referring to? How did you get to that path E:\\_DERIVATIVE\\Gitlab\\TDPyEnvManager\TDPyEnvManager_venv_venv ? It’s a local path.

I just tested latest release and my dev env and it worked as expected.

I’ve started on these RFEs in a branch. But because of the added flexibility to vEnvs, which were meant to be straightforward vs conda, it is now getting closer to conda in term of feature set and I am working on unifying the parameters at the component level and consolidating some methods.

It’s taking a bit of time as I was also busy with other pre-release tasks and now taking some time off.

I’ll get back to it first thing in late November / early December.

Best,
Michel

Hi Michel,
actually, that was one me. I played arround with deleting the suffix and readded the suffix, but as _venv, and not _vEnv, which brings me to the topic that it seems like that you are purposefully appending the _vEnv suffix if it is not present, which I find a curious choice.
But thanks for the headsup, so going to use the .packagefolder approach onwards until changed arrive. Looking forward!