SasView fails to copy the default config file to the .sasview/config folder as custom_config.py

[smk78]

This issue replaces https://github.com/SasView/sasview/issues/1534 and https://github.com/SasView/sasview/issues/1640.

Platforms affected

Behaviour described has been observed on Windows (mostly W10), MacOS (Mojave) and Linux (CentOS).

Symptom

On trying to run a new install of SasView 5.x an error message appears 'unable to execute script sasview'.

Details

Copied from #1534 :

From a recent user report on Windows 10 who also sent on the entry from the log file it was clear that SasView was failing to copy the default config file to the .sasview/config folder as custom_config.py .

The offending code was from src/sas/_config.py

def setup_custom_config(app_dir, user_dir):
    path = make_custom_config_path(user_dir)
    if not os.path.isfile(path):
        try:
            # if the custom config file does not exist, copy the default from
            # the app dir
            shutil.copyfile(os.path.join(app_dir, "custom_config.py"), path)
        except Exception:
            logger.error("Could not copy default custom config.")

the reported error was coming from the last line suggesting a failed attempt ad shutil.copy. Manually copying the default config.py from the source to the .sasview directory fixed the problem.

Copied from #1640 :

The Linux release binaries for SasView versions 5.0.1 and above give the following error when executing the run_sasview.sh script:

ERROR: Could not copy default custom config.
Traceback (most recent call last):
  File "sasview.py", line 117, in <module>
  File "site-packages/sasview-5.0.1-py3.6-linux-x86_64.egg/sas/qtgui/MainWindow/MainWindow.py", line 62, in run_sasview
  File "site-packages/sasview-5.0.1-py3.6-linux-x86_64.egg/sas/logger_config.py", line 43, in config_development
    self._disable_debug_from_config()
  File "site-packages/sasview-5.0.1-py3.6-linux-x86_64.egg/sas/logger_config.py", line 50, in _disable_debug_from_config
    custom_config = get_custom_config()
  File "site-packages/sasview-5.0.1-py3.6-linux-x86_64.egg/sas/__init__.py", line 44, in get_custom_config
  File "site-packages/sasview-5.0.1-py3.6-linux-x86_64.egg/sas/_config.py", line 98, in setup_custom_config
FileNotFoundError: [Errno 2] No such file or directory: '/home/my_home_folder_goes_here/.sasview/config/custom_config.py'

Version 5.0.0 works fine and creates the custom_config.py file upon first launch. Once this file exists, versions 5.0.1 and above also launch.

[smk78]

I wonder if one or other of these may be related?

https://stackoverflow.com/questions/40716346/windows-pyinstaller-error-failed-to-execute-script-when-app-clicked

https://stackoverflow.com/questions/404744/determining-application-path-in-a-python-exe-generated-by-pyinstaller

[butlerpd]

Upon further testing it appears that there are two separate problems involved:

• In a few cases the SasView 5.0.3 installer fails to install the .sasview folder much less anything beneath it. There does not appear however to be in any indication of the failure. When working correctly the installer will create a .sasview folder with a config subfolder along with the custom_config.py file. Note that in 5.0.3 it also creates a boatload of subfolders to the config folder which do not exist in SasView 4.x.
• It seems that SasVIew 5.0.3 on windows 10 will never copy the default config.py to sasview\config\custom_config.py. It can create a .sasview folder if missing and a config folder with that but the rest is empty.

Since the second (reliable) bug only kicks in for a fresh install (no pre-existing .saview with its own custom_config.py) in the rare cases where the first this problem manifests, this second bug would rarely be an obvious issue to any user. This probably explains why the issue is only rarely reported despite the second bug being very reproducible.

To date this has been carefully tested in documented on five windows 10 machines including 3 desktops running Windows 10 home, Windows 10 Pro, and Windows 10 Enterprise respectively and 2 virtual machines on paperspace.com. These two virtual machines report running Microsoft Windows Server 2016 Datacenter. None of the five can copy the config.py file and will produce the script failure error if custom_config.py is removed from the config folder (this is not the case with 4.x but previous versions of 5.x have not yet been tested). However only one of the two datacenter virtual machines would not install the files in the first place. This was tested a couple of times to ensure reproducibility.

Interestingly the two virtual machines were configured identically but one is rarely used other than to test a particular version of the SasView installer while the first is used as a development machine as well as a workhorse Windows desktop. The one rarely used machine installs 5.0.3 properly while the other fails. This suggests that it is something about the configuration of the local machine that prevents the installer from doing its job?

LATE EDIT NOTE (Sep 2021):

• The issue reported of the installer not installing except on one datacenter machine turns out to have been the OneDrive issue and .sasview was being properly installed to OneDrive. The one Data Center machine I used that did "properly install" did not have a OneDrive and thus worked as expected
• It seems that in fact, during a clean install, the installer also copies a clean custom_config.py. So the only time the script failure should occur is when it is trying to run from a different drive than things were installed in, or the custom_config.py somehow was removed.

[smk78]

User Jean-PaulC reports:

I have installed Sasview 5.03-win64 on windows 10. I can easily launch the Sasview.exe program. If I save a project (sasview.svs ) I will not be however able to re-open it by double clicking. An error message appears: ‘’Failed to execute a script sasview ‘’. I need then to open the sasview.exe program and then open the project. Which is not really convenient.

2020-10-01 17:32:30,977 : INFO : root (GuiUtils.py:144) :: Custom config path: <module 'custom_config' from 'F:\\Users\\XXXXXX\\.sasview\\config\\custom_config.py'>
2020-10-01 17:32:40,102 : INFO : sas.sascalc.fit.models (models.py:175) :: plugin model dir: F:\Users\XXXXXX\.sasview\plugin_models
2020-10-01 17:32:40,102 : INFO : sas.sascalc.fit.models (models.py:175) :: plugin model dir: F:\Users\XXXXXX\.sasview\plugin_models
2020-10-01 17:32:40,687 : INFO : root (GuiManager.py:109) ::  --- SasView session started ---
2020-10-01 17:32:40,687 : INFO : root (GuiManager.py:111) :: Python: 3.6.10 (default, Mar  5 2020, 10:17:47) [MSC v.1900 64 bit (AMD64)]
2020-10-01 17:33:52,379 : INFO : root (GuiUtils.py:144) :: Custom config path: <module 'custom_config' from 'F:\\Users\\XXXXXX\\.sasview\\config\\custom_config.py'>
2020-10-01 17:34:43,743 : INFO : root (GuiUtils.py:144) :: Custom config path: <module 'custom_config' from 'F:\\Users\\XXXXXX\\.sasview\\config\\custom_config.py'>
2020-10-01 17:36:00,769 : INFO : root (GuiUtils.py:144) :: Custom config path: <module 'custom_config' from 'F:\\Users\\XXXXXX\\.sasview\\config\\custom_config.py'>
2020-10-01 17:42:34,257 : INFO : root (GuiUtils.py:144) :: Custom config path: <module 'custom_config' from 'F:\\Users\\XXXXXX\\.sasview\\config\\custom_config.py'>
2020-10-01 17:44:01,115 : INFO : root (GuiUtils.py:144) :: Custom config path: <module 'custom_config' from 'F:\\Users\\XXXXXX\\.sasview\\config\\custom_config.py'>

So he can run the program from the shortcut but not by file association.

[butlerpd]

The inability to launch from the file association has been a long standing problem as I recall - fixed and unfixed at various times. .. was going to ask for the log output but I see it is now added. Not showing the error unfortunately but looks like it is taking 10 minutes to fail? --- SasView session started --- at 5:32PM and the last checking for the custom_config module is at 5:44PM?? We should test but I vaguely recollect an issue on this from a while back that was never closed?

[smk78]

Tried a few searches but couldn't find an obvious ticket. (I know that by posting this @krzywon will find it instantly!) :-)

[krzywon]

You're looking for #527 @smk78 😃

[butlerpd]

🤣 Challenge issued, challenge accepted --- better known as: veni, vidi, vici 😄

[smk78]

How does he do that?!

My suspicion here is that when the User is double-clicking on the project file it is actually calling SasView but it is then failing for the now well-documented reason above. But then it is mighty odd that the User can start the program directly!

[butlerpd]

indeed, it cannot be failing exactly in this way because this failure happens on the copy command which issues an error to the log file (in the except part of the try/except) prior to collapsing. It does seem to be related as it seems to be looking for custom_config. I wonder if it is a path issue when invoking SasView from some random place on disk (i.e. wherever the project file lies?

[smk78]

User SabrinaG (ISIS) reported to help list:

I’ve just installed version 5.03 on my Windows 10 laptop. – It fails to run.

**1st attempt:**
Installed for all users, directly in C: as recommended.

Observed behaviour:
•   Mostly: “Fatal Error: Failed to execute script sasview”
•   Occasionally: SasView appears to launch, then windows error report window pops up and asks to close the program
(This happens only when running as administrator, but is not reproducible.)

I have tried:
•   Running as administrator (occasionally produces a different error, see above, but never runs)
•   Re-installing
•   Running from desktop shortcut, start menu link, and directly from installation folder by running sasview.exe
•   Deleting .sasmodels folder (following github error documentation)

**2nd attempt:**
Installed only for me, directly in C: as recommended.

Observed behaviour:
•   Always: SasView appears to launch, then windows error report window pops up and asks to close the program

I have tried:
•   Running from desktop shortcut, start menu link, and directly from installation folder by running sasview.exe
•   Restarting computer

@smk78 asked Sabrina to work through the procedure in https://www.sasview.org/faq/#why-will-sasview-no-longer-start

Sabrina responded:

I have worked through this troubleshooting as well.
The log did show the config file error message.
Config folder was empty.
I have copied across the config file. (no change)

**3rd installation**
(for me only, recommended directory)
Checked config folder before running anything: this time it contains lots of sub directories and it contains the config file.
Same behaviour as with 2nd installation.
Same error messages in log file (attached).

@smk78 then suggested she try running sasview.exe from a cmd window to see if any messages appeared there (there were none), and also suggested she look in the Windows Event Viewer.

Sabrina responded:

I should mention that earlier this morning, I installed SasView 4.2.2 as well, hoping that this might run at least. It doesn’t. Same apparent behaviour as 5.0.3 when running sasview.exe in any way.

What changed is the behaviour around the log file (attached) and the config file.
[sasview.log](https://github.com/SasView/sasview/files/5730365/sasview.log)

5.0.3 has stopped writing to the logfile since I installed 4.2.2.
4.2.2 creates a custom_config.pyc file everytime it is launched (5.0.3 doesn’t).
So although from a top level, they seem to behave the same, 4.2.2 seems to get a bit further [in that both versions now display the splash screen] and at least executes the config file before crashing.

I’ve had a quick look in the event viewer (learned something new).
There are various entries relating to SasView, but I’m not sure, what I’m looking for.
This might be a case for screensharing.

@smk78 and Sabrina then had a Zoom call during which the following was established:

• ~3yr old Lenovo laptop, 16Gb RAM
• CPU: Intel Core i7-8550 / GPU: Intel UHD 620
• supplied with W10 from new, currently Build 18363 (ie, latest)
• DirectX v12 (ie, version shipped with W10)
• SAS_OPENCL = 'None'
• Event Viewer indicated multiple instances of AppCrash relating to SasView
• 2 files were implicated: igdrclneo64.dll and igdlh64inf.inf
• the first of these is the OpenCL driver for Intel UHD graphics chips
• Sabrina's driver is dated 19-Nov-18, v 25.20.100.6444
• Interestingly, @smk78's driver is dated 19-May-2020, v 27.20.100.8280 (same W10 build, but a UHD 630 not 620)

Question: does SasView check for the presence of a GPU when it starts up, irrespective of the SAS_OPENCL setting?

[smk78]

User LeiZ has reported that on his W10 machine the .sasview and .sasmodels folders were being created in his OneDrive folder (C:\Users\\OneDrive) and this led to the 'unable to execute script sasview' error. When he copied the SasView folders up one level the program started working! @smk78 has updated the FAQ page of the website about this.

[rozyczko]

C:\Users\<username>\OneDrive

WHERE???

[RichardHeenan]

Yes really, Microsoft strikes again, "OneDrive" appears as a (virtual?) folder in C:\Users\username\ along with the .sasview folder etc

[smk78]

Only if you, or your well-intentioned(?) IT Department, or your OEM, enable the feature. You can kind of understand the benefit of doing so. The issue, I submit, is whether there is a way to know whether it is enabled so that SasView can be directed to look there.

[rozyczko]

The installer copies custom_config.py to

{userdesktop}\..\.sasview\config

where {userdesktop} is an internal installer shortcut to c:\users\<current_user>\Desktop

The only other thing copied with {userdesktop} is plugin_models subdirectory.

[butlerpd]

aha... but I believe that in fact {userdesktop} is probably pointing to c:\users\<current_user>\Desktop\OneDrive in most default new installations of Windows 10. I have been bitten by that recently have put things on \Desktop or \users and then not being able to find the file I just put there ... because it turns out it was in the similarly named directory on the OneDrive disk. Very bad form of Microsoft IMHO

[smk78]

%USERPROFILE% is an environment variable for the users profile C:\Users{username} %OneDrive% is an environment variable for C:\Users{username}\OneDrive But there is no environment variable for the default/preferred save location.

support.microsoft.com says that the regkey HKCU\Software\Microsoft\Office\16.0\Common\General\PreferCloudSaveLocations can be set to 0 to Save to Computer by default, or perhaps in our case which could be tested to see which of the above locations is in use, however I have OneDrive, my default save location is set locally, but I do not seem to have this key in my registry! So this does not seem to be a wholly reliable test.

I wonder therefore if we would be better moving .sasview and .sasmodels to a \SasView in %APPDATA% which is supposed to be the 'default user data location'? The only real downside I can see with doing this is that %APPDATA% is normally a hidden folder so in your File Explorer you need to go to the View tab and check Hidden Items to see it.

Thoughts?

[RichardHeenan]

Can the sasview installer simply extract username or current_user and copy more explicitly to the required directory instead of using {userdesktop} ?

Or perhaps sasview could be persuaded to run from the files on Onedrive, but that might be harder? (Though may have the advantage that custom models etc are available whichever machine a user is logged in to as Microsoft is likely intending ???)

This needs an expert to work out a consistent system, and maybe a test script or two to copy some files and do a dir to see where they actually go?

[smk78]

%USERNAME% will return just the username.

@rozyczko / @butlerpd : Where are we getting {userdesktop} from? Are we 'creating' it? Why not use %USERPROFILE%?

[rozyczko]

As mentioned, {userdesktop} is a built-in variable in the INNO scripting language. We have been using INNO Setup for generating installers for Windows since forever (3.x ?) We can probably change that to {userappdata} which is just %APPDATA% but as you said, this would hide the location. Seeing that %APPDATA% is %USERPROFILE%\AppData, we might change the copy target to just {%USERPROFILE%}. This should be unequivocal, since it always points to <system_drive>\Users\<current_user>.

[rozyczko]

https://github.com/SasView/sasview/pull/1723

[krzywon]

A student at the NCNR neutron school is having this issue with 5.0.4 RC2. The .sasview directory is created in the C:\Users\<username> directory as expected. He followed the instructions in the FAQ but is still unable to get SasView to load. @wpotrzebowski and @smk78 any other ideas?

[butlerpd]

Please note that there are actually two problems here: the first is the failure to copy which will always happen on a new machine and leads to the script failure error. However, when we manually copy the default_config file over to the .sasview/config directory, SasView starts (no more script error) by showing the splash screen then silently crashes with absolutely nothing logged to the sasview log file. We've seen this behavior once before as I recall but not sure what the answer was.

NOTE: also checked his OneDrive and there is no .sasview folder there either.

[rozyczko]

Hmm so .sasview is created but its content (config) is not copied at install time? This sounds bad.

showing the splash screen then silently crashes with absolutely nothing logged

Is there anything special about user's hardware/OS? Any chance to try out 5.0.3?

[butlerpd]

default_config is copied at startup. Is it also copied at install? but just to be clear this is a long standing problem that I believe is universal to all windows 10 machines and probably all windows machines.

To test this, delete or move the default_config file from the .sasview/config folder. Next start SasView. It will fail with the startup script error due to the failure to copy the default_config file (the line number and file that is the culprit is documented in the log file). I have yet to find a situation where this does not happen.

If the default_config file is also copied at install time then it means that is sometimes (or always) failing as well. I would not know how universal that is.

[smk78]

@krzywon / @butlerpd : is the student able to 'run as administrator'? Does that allow SasView to start properly?

[bmaranville]

This library is maintained by reputable folks... It might help. https://github.com/ActiveState/appdirs EDIT: I see that appdirs is already in the developers toolkit - please disregard noob comment above.

[AlQuemiste]

Attempting to run SasView 5.0.4 with run_sasview.sh, I encountered the bug #1672 with

• Debian Buster (4.19.194-3) x86_64
• Python 3.7.3

I resolved the issue via using the source code available from https://github.com/SasView/sasview/archive/refs/tags/v5.0.4.tar.gz and manually copying sasview-5.0.4/src/sas/sasview/custom_config.py to $HOME/.sasview/config/. There seems to be a minor bug in the Python script, sasview-5.0.4/src/sas/_config.py, in the function setup_custom_config.

[butlerpd]

Keeping this open as long as we get install errors. So moving now to 5.1

[butlerpd]

Verified using 5.0.5RC2. Removing the custom_config.py causes the SasView program to fail to start with the usual entry in the log file: Could not copy default custom config. However, the error that pops on my windows 10 screen is not the Failed to execute a script sasview error. Instead A big box with a white x on a red background label: Unhandled exception in script pops up. It gives a full error and then a traceback in a scrollable window. Unfortunately ip points to the line after the actual copy failure.

[lucas-wilkins]

Should be resolved by #2164

[jrt-lanl]

Didn't read the entire thread, but my "solution" was that I installed under an admin account; so, I ran as admin and worked fine (config folder was populated).

[smk78]

Didn't read the entire thread, but my "solution" was that I installed under an admin account; so, I ran as admin and worked fine (config folder was populated).

Thanks, @jrt-lanl . Unfortunately that "solution" is not one that is available to many SasView users, for example, those in the commercial sector! However, as @lucas-wilkins comments before you, we are now pretty confident that we have a more robust and universal solution. We're hoping to role it out in 5.0.6 in early 2023.