OpenTAP Package Cache location

Hi everyone,

As of the latest 9.18.5 OpenTAP version, the PackageCache folder has been moved to the C:\Users\XXXX\AppData\OpenTAP\PackageCache as compared to the 9.10.4 where it was located under C:\Program Files (x86)\Test Automation\PackageCache. Here, XXXX is the user account that was logged in to install OpenTAP.

Is there a way to install across all the users such that it can be accessed regardless of the windows account used to log in?

Hi Antonio,

Currently, I think that is not possible.

Can you explain why you need this? Maybe there is an alternative.

Hi @rolf_madsen,

Thanks for the reply. Since our application is used by different users, there is a chance whereby the windows user logged in may be different from the user that installed OpenTAP. This results into the particular user not being able to access the packages cached/installed by other users.

Hence, we wanted to check the feasibility on such use cases. Do you have alternatives in mind?

If you have a shared set of packages, you can create a shared folder and add that as a package repository in the repository settings.

Of course that is a bit of a manual action, but this can be useful. You can also use this with shared network drives.

Thanks for the suggestion. However, we are already doing that for shared set of packages - and that is not the problem here. Our problem is that when OpenTAP is installed - it installs the packages and caches them in the C:\Users\XxXx folder for that specific windows user. This results into the packages that were cached to not be accessible by other windows users.

Is there a solution for this?

I think there there is no way to do what you ask currently, but I also still don’t understand your usecase. Why is it necessary for the other users to access the packages through the cache and not the package repositories?

For our use case, the test stations that uses OpenTAP are used by multiple windows users. All of our applications are all user-wide settings, however OpenTAP restricts us to the specific user directories. Due to this, even though the packages are present in the user directory, we would still need to install from the central repository - requiring a network call. This deviates from the previous behaviour whereby the package cache was accessible by all users from the Test Automation folder.

OK, I get it now. This is mostly a performance issue for you or is network stability also a factor?

Anyway, it is still a bit surprising to me that this is a problem. Is it constantly new users accessing the stations?

Would it help if this was a setting?

Thanks for the continuous response @rolf_madsen.

Yes, it is a performance issue for us when the users need to install from the central directory. Hence, it is important for us to cache the installed packages.

Could you elaborate more on this approach/idea of having it as a setting? This will help us decide whether this could be helpful for us.

Got it.

Maybe there is a simple change we can make to OpenTAP which could help you without changing the behavior for everyone else.

For example:

  1. A setting, for example inside the engine settings it could be possible to set the location of the package cache and have everything use it.
  2. An environment variable, e.g OPENTAP_PACKAGE_CACHE_LOCATION, that you could specify to point to your alternative package cache location.

Or both? Or something else?

I think the environment variable would make more sense for us due to the following reasons - [1] we don’t distribute the engine settings to our test stations and [2] The engine settings wont be available during installation (assuming its a fresh installation), which means the default packages may still be cached in the default location. @rolf_madsen, what are your thoughts?

@brennen_direnzo Would it be possible to release this as a seed release for 9.18.5?

1 Like

@antonio.quizon I don’t think we will be able to get this into 9.18, but @rolf_madsen has already implemented this fix with the environment variables and it can be available in 9.19: