Improvement: Support custom installation directory and choose between bundled or existing uv/Python

[RyanY11]

First of all, I’m very glad to see the modernization efforts in PsychoPy, especially the switch to the Node/Svelte/Electron frontend framework!

After downloading and installing, I noticed the following issues:After running the installer, two folders are automatically created under the default path C:\Users\MYUSERNAME\AppData\Roaming: psychopy3 and psychopy4. I’m wondering if psychopy3 is a wrong naming?

Another issue: inside the psychopy4 folder, uv and Python are automatically downloaded and installed. However, I already have my own existing uv and Python environments on my system, and this has made my local environment setup more complicated.

Therefore, I was wondering if it would be possible to:
Let users specify a custom installation path during setup, instead of using the default AppData\Roaming location.

Provide two installation modes:
A default mode for regular users, which installs the full bundled uv and Python environment (consistent with the previous standalone version).
A custom mode for experienced users, which only installs the frontend framework to a specified directory and allows users to select their existing uv and either create or use an existing Python environment.

I understand the project is still in an early stage, and this may not be a top priority right now. However, this would likely improve the user experience significantly.

Thank you!

[TEParsons]

As the executables in the .uv folder are just downloaded and run by path (rather than installed to the system), I think it does use your system uv cache; if I cd to my psychopy4 folder and call .uv/uv python find 3.10 I get the same result as if I call uv python find 3.10 from my documents folder, and if I clear my cache then install psychopy-lib manually on another venv, uv still uses the cached dependencies when Studio then installs it to its own venv. I can see the appeal of having a custom location for Studio's environments though, it's one to think on.

w/r/t the psychopy3 folder, it's because the PsychoPy library still makes itself a folder for its prefs, independent of Studio. When you run an experiment from Studio, it sets up the prefs from a JSON string, but the original prefs file and directory still get made when the library is imported as it would need it if you weren't running from Studio. When we eventually drop the Standalone app and move fully over to Studio we'll likely change the library to only use the psychopy4 folder.

[Joecstarr]

Have you considered using an optional environment variable for this behavior? Something like:

export PSYCHOPY_PREFS=$(pwd)

this would let you have:

• user environments
• system wide environments
• project specific environments

From what I can see this would be an easy way to get this behavior without a large change set.

It could be done by replacing

app.getPath("appData")

with a wrapper which conditionally finds appData or the environment variable. (The "correct" value should probably be stored on first call and referenced on subsequent calls. )

---

Something similar can be done right now on linux and windows by setting %APPDATA% or XDG_CONFIG_HOME. This probably isn't a great idea as it squashes the variable for the other applications.

[TEParsons]

We do have a system for setting prefs already - we read/write from a file in the user's folder (see https://github.com/psychopy/psychopy-studio/blob/dev/electron/src/preferences.js), so we could have the location of the .python folder set there.

Since this issue was raised I've actually been chatting to some IT administrators at universities to see what would make their lives easier and have added a toggle to choose between a user folder and a global folder for the location of the Python venvs (see #88). The question is whether to add a "Custom path..." option; I'm still figuring out how useful that is, seeing as the venvs are already fully editable via UV and now can be in user or global space. What's the advantage of pointing to an existing environment rather than customising the environments created by Studio?

[Joecstarr]

I saw how you were handling preferences, that's why I mention app.getPath("appData"). I wouldn't change the location of just the .python directory. I would either make the whole preferences folder moveable or I would remove .venv handling from the tool. From a pure design perspective I think letting users manage their python environments is better (which is what @RyanY11 seems to be suggesting). However, I also understand the user base may not have have the computer chops to do that (seeing IT guys as the primary installer/maintainer is probably a good plan).

My suggestion is to keep everything the exact same from a program flow perspective. The only difference would be to add a layer of abstraction to allow customizing where the tool looks for the preferences folder. This would at least partially solve @RyanY11's problem by making and using a brand new set of preferences (including a .venv) whenever needed/wanted. The use case this adds is

The user wants to maintain project specific psychopy environments.

For reference, here's a scenario this solves:

1. Bob starts a new project called used-badger
2. Bob decides to use plugin A in used-badger
3. Bob installs plugin A into the psychopy managed .vevn
   - Plugin A has a hard dependency on libraryX==1.0.0
4. Bob starts a new project called tubby-turtle
   - tubby-turtle and used-badger are run on alternating days so need to share a working environment
5. Bob decides to use plugin B in tubby-turtle
   - Plugin B has a hard dependency on libraryX==2.0.0
6. Bob attempts to install plugin B into the psychopy managed .vevn

This scenario results in a dependency conflict between tubby-turtle and used-badger. This can be resolved by directly managing the psychopy environment (or rebuilding) between runs. However, I think configuration management/user support in that case isn't fun.