Support for extension dropped; new onboard function replaces extension functionality

English
#1

I have been using a Calc extension, XPysort, for several years in support of a user. Support for the extension has evidently been dropped, but a new onboard sort function effectively replaces it.

My problem is I have about 5 years of historical spreadsheets my user occasionally needs to access. If she tries to use the new version of Calc, these historical files won’t open correctly. She can use an older version, but then that older version cannot be used to build new sheets because the extension is not supported.

As we go forward, I can either try to maintain two versions of LO Calc for her and instruct her to use the correct one depending on the age of the file she wants to open, or I can go back in history and rewrite the files to use the new onboard function. Either of these approaches seems clunky, so I was wondering if the experts here had any advice for me.

Background of my experience can be found here.

Thanks very much for any advice

#2

In such situation, my recommendation is to try minimizing the workload.
Your solution to maintain two versions looks fine, if, most of the time, the old documents are used for reference only, not for update.
If, from time to time, an old document needs update, then I would recommend to update it in a way that it doesn’t require XPysort anymore.
I would use a clear naming convention by appending _old to the names of the old documents may help in the process.

1 Like
#3

If the extension issue cannot be resolved readily, you could parallel install an older version of LibreOffice just to work with the old extension while keeping a more modern version for other work. Installing several versions of LibreOffice in parallel - The Document Foundation Wiki

1 Like
#4

trying to sort out what the actual problem is, have to go down convoluted posts / bug report / zip / ods … :face_with_thermometer:
would be wise to narrow this down with the simplest possible example.
would make sense to add “python” as tag of this topic :wink:

would then first quantify it :wink:

which is how many files ?
calls to the failing python code ?
to be replaced by what ?

#5

LO Calc evidently no longer supports the XPysort extension, which I’ve used for the past 5 years or so in support of my user. The XPysort functionality has been effectively replaced by a new “Sort” function in Calc, so as I continue to build spreadsheets for my user, I can use this new sort function instead of the old XPysort. The problem I’m reporting is if I convert my user to one of the latest versions of LO Office, she won’t be able to open any of her old spreadsheets. @EarnestAl and @Steph1 have provided a couple options for me to look in to.

Whatever I do needs to be transparent to my user, as she is not computer-savvy. For example, if I opt for a two-version solution, then it would be great if Windows opened the “correct” version on double-clicking a file based on it’s age or something similar, for example. (She also uses LO Calc for other things unaffected by the XPysort issue.) But, I digress.

I believe the problem I reported two years ago and for which a bug report was written, is well-documented here. I’ve included that link here only for background, in case someone wants to look into the original problem. You apparently are interested, and I appreciate that. I did update that original post (and the bug report) recently, but I’ve gotten no feedback on those updates. Frankly, it’s been two years since I reported that problem, and I’ve given up on a “fix” for it, especially since new onboard functionality replaces it. So, in particular, python is not part of the problem I’m reporting here. That leaves me with the “multiple versions” problem I’m seeking advice on here.

I build one spreadsheet per month for my user, and there are 9 months in her fiscal year. So, over a 5 year period, there are 45 files to be re-written. Re-writing them would involve changing one line in each spreadsheet that replaces the call to XPysort with a call to the new Sort function. It would probably require a few hours work on my part.

#6

There should be no problem using old extensions with newer versions - we almost never make compatibility-breaking changes (at least purposefully). Do not assume that some support was dropped; instead, just file a bug report. A new functionality that duplicates the extension is not a reason to drop any support.

EDIT: I have tested the extension using Version: 25.2.3.1 (X86_64) / LibreOffice Community
Build ID: d8d1af5f77df955194e52baabe19324532ac8e8b
CPU threads: 24; OS: Windows 11 X86_64 (10.0 build 26100); UI render: Skia/Vulkan; VCL: win
Locale: de-DE (en_US); UI: en-GB
Calc: CL threaded

and it works just fine (I used an array formula like {=PYSORT(A1:A10)}, on a random integers in A1:A10 - and the result is the correctly sorted data).

#7

Thanks for your feedback and support. I’ll try to use the XPysort function again and report back. If it does, then this problem goes away.

Please note that I assumed support was dropped because I got no response to my re-test of the bug report.

#8

Please don’t assume any responsibility of anyone to provide timely replies (especially in the bug tracker). Additionally, bug tracker is not any kind of help desk - it’s a tool for developers, meaning, that bugs are created and improved by interested parties with sole purpose of making it possible for a developer to take it and work on it to fix / implement. Thus, there is no requirement to answer any comments there - the comments will add more relevant info, and that info could be useful to a developer when they happen to get interested in that bug.

(Just to establish correct expectations, and avoid confusion like that.)

#9

I understand your point about responsibility. As a user, I only know what I see here and in the bug report. I saw nothing in either place even though I did respond to the request to re-test. So, seeing no response and being unable to get the extension working, I assumed support for the extension was dropped and moved on to try to figure out how to handle that.

Another solution I neglected to mention above is to keep my user on version 7.2.7.2, which supports Xpysort and filtering on the results.

Note that I have managed to install XPysort on the following version of LibreOffice:

Version: 25.2.2.2 (X86_64) / LibreOffice Community
Build ID: 7370d4be9e3cf6031a51beef54ff3bda878e3fac
CPU threads: 12; OS: Windows 11 X86_64 (10.0 build 26100); UI render: Skia/Vulkan; VCL: win
Locale: en-US (en_US); UI: en-US
Calc: threaded

The extension installs and sorts data correctly, but I can’t filter on the results. That filtering problem is not present in version 7.2.7.2. The filtering problem is the bug we reported about two years ago. It’s still present.

I’m afraid I’m confusing this thread with multiple issues now, so I will try to clarify where I stand: I can’t use XPysort with newer versions of LO Calc because I can’t filter on the sorted results. I can filter on sorted results if I use the new onboard Sort function, and I can filter on sorted results if I continue to use version 7.2.7.2 and XPysort.

So, I have these alternatives:

  • Continue to use LO 7.2.7.2 for the foreseeable future
  • If a fix is implemented for the filtering problem, upgrade to the latest version of LO and use either XPysort or the new onboard Sort function, since both will work
  • Adopt a multiple version solution using latest versions of LO plus the onboard sort function for newest files and 7.2.7.2 for old files

I guess unless there are compelling reasons to upgrade to the latest version, the first option involves the least work.

I look forward to any feedback, and appreciate your patience with me.

#10

the more reasonable sounds to have a macro for that :

and even not sure how 45 one-liners could amount to “a few hours” :wink:

Impressum (Legal Info) | Datenschutzerklärung (Privacy Policy)   Content on this site is licensed under a Creative Commons Attribution Share Alike 3.0 license.