You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
We have a set of shared directories on dropbox for a group of analysts. Some of these directories are editable and some are viewable, but not editable. We have xloil-python code saved in one of the viewable directories and several models in excel that use this code saved elsewhere in editable folders.
Recently several users reported that their models fail to load xloil (despite it working fine the prior day). I noticed that there was a pycache folder and a python file (dated from 2023 and named the same as the model sheet) saved in the folder. Users are not explicitly creating this and the symptom is that they can't initialize the model. There is also nothing in our python code that would do something like that.
Deleting the py file, pychache folder, removing the xloil vba module and re-opening seems to fix the issue and loads xloil from the right location. Understandably this is very annoying for the user.
Is there anything in xloil that would lead to this kind of thing? I can't seem to find anything like this in the documentation. It's also very strange that the py file has a date so far back in the past, but is named the same as the latest name of the model sheet file.
The text was updated successfully, but these errors were encountered:
There is a mechanism which detects when a workbook is saved under a different name and copies the associate py file (if one exists) to the new name. It's likely this is somehow being triggered. What is the contents of the py files being created? What mechanism are you using to load the code from the read-only folders? If you set log level to debug you can see the WorkbookRename event firing which may give some clues. I'll also look at providing an option to disable this feature
The users do periodically save the excel file with a new name as a form of version control. However, the py file doesn't appear every time this happens.
The contents are an old version of the expected python file that should be loaded. As I mentioned, the file gets a date from 2023 and the current version of the python file has a date of 2024. Additionally, the file that gets created loads another python file and that file doesn't get copied. The file is loaded by having the py file listed in xloil.ini:LoadModules list. The module python file is not named the same as the workbook (e.g. woorkbook might be named ModelXYZ.xlsb and the module is Helper.py)
Another interesting thing is that we have other models in a different folder where this has never happened.
I will try to set debug logging, but I have not been able to consistently replicate the problem so may take a while to get info from that.
We have a set of shared directories on dropbox for a group of analysts. Some of these directories are editable and some are viewable, but not editable. We have xloil-python code saved in one of the viewable directories and several models in excel that use this code saved elsewhere in editable folders.
Recently several users reported that their models fail to load xloil (despite it working fine the prior day). I noticed that there was a pycache folder and a python file (dated from 2023 and named the same as the model sheet) saved in the folder. Users are not explicitly creating this and the symptom is that they can't initialize the model. There is also nothing in our python code that would do something like that.
Deleting the py file, pychache folder, removing the xloil vba module and re-opening seems to fix the issue and loads xloil from the right location. Understandably this is very annoying for the user.
Is there anything in xloil that would lead to this kind of thing? I can't seem to find anything like this in the documentation. It's also very strange that the py file has a date so far back in the past, but is named the same as the latest name of the model sheet file.
The text was updated successfully, but these errors were encountered: