sudo install depends on the package being available in the repository many flavours of Linux do not have it hence the error message.
You have to install orjson and then GRAMPS to a virtual environment, some parts of GRAMPS are then contained within the environment and others not. Thus GRAMPS 5.2.4 not in the environment and 6.0.4 in the environment can coexist on the same PC quite happily it seems so far.
As easy as that, if the package is available for the release of Linux installed. For example Ubuntu 24.04.3 LTS (aka Noble) doesn’t have a backport of python3-orjson.
Today I attempted to file a backport request using requestbackport python3-orjson -d noble and this was at the end of the output, which leaves me unsure of what happened, and what I should go next. No email acknowledgement or anything. Will wait a week or so and try again:
The source package ‘python3-orjson’ does not exist in the Ubuntu primary archive in questing for pockets Release, Security, Updates, Proposed with status in Pending, Published
BTW, as @comeng mentioned, I do have a virtual env for development where I run Gramps from source along with orjson installed via pip. The issue is when installing Gramps and the python3-orjson package isn’t available for installation.
The issue is when installing Gramps and the python3-orjson package
isn’t available for installation.<
Going forward to Trixie it would appear Raspberry Pi in particular is
going to be even stricter in enforcing (they have moved from
recommending) the use of the “venv” for reasons of “system protection”.
Whether other flavours of Linux go down this route I have not investigated.
My next move is to look at the “venv” on my main system LMDE6, all my
playing around has been on the Pi where simply swapping the SD card to
the backup gets me back to square one.
phil
I thought orjson was a big deal in terms of speed for GRAMPS I would have thought the majority of users would be on Windows or MAC (who do not seem to be having issues) and what I have seen so far would suggest “venv” is entirely viable so why add in more complications for the GRAMPS development team.
Perhaps the Prerequisites Checker could be made into a stand-alone Tool with expanded links to troubleshoot? Or to point at proven solutions?
The orjson and Windows Thread Director issues spring to mind first.
But are there still situations where the Geography views aren’t supported without installing some library?
Also, the infatuation with GraphView/GooCanvas prerequisite Charts views seems to be growing. There have been suggestions to make FTV by @ztlxltl into the default Chart.
And the growing interest in AI tools implies another challenge where the prerequisite is variable.
I may be naive in assuming that we want the Gramps user base to have an excellent experience installing and running Gramps out-of-the-box. I believe that when a software installation fails or installs and doesn’t run, it is a situation that potentially drives away one user at a time.
My primary platform isn’t Linux so I struggled to set up orjson in an Ubuntu 24.04 development environment (not for genealogy research/usage), and I spent a chunk of my time researching and resolving the issue. Should we expect each end user to do the same in order to use Gramps 6?
Case in point: our excellent bug triage team regularly advises users to upgrade to Gramps 6 when a bug is filed. We can suggest/advise they need to upgrade their OS, request backports, etc. to make Gramps 6 run, but when there’s a possibility we can make Gramps work out of the box, why not?
A user is struggling with the decision about orjson on the Dansk Gramps brugergruppe Facebook group. @kmikkels is willing to do the support in native language. But it means 2 more people unfamilar with orjson and how to determine if it is needed on a specific Linux distribution.
The sticking point is determining if there will be a compatibilty problem to resolve so that they can plan their upgrade.
In this case, if there IS a problem, they need to leave enough time to have their support person respond and that person run experiments in an unfamilar OS, translate a process described in English here, or request additional Help. And to run that indirect cycle for multiple exchanges.
So, it would be better if there was a process to do an orjson test before starting to install and discovering their Gramps will be unusable for an unpredictable span.
Or to have an initial install without the need for orjson. Then a Performance Enhancing orjson addon (with the prerequisite) that supersedes the basic json-using modules.
Perhaps the Prerequisite Checker (for the Gramps 5 family) should be enhanced to have a section for tests before upgrading?
I tossed together a SuperTool script that has the kind of gentle encouragement that might be included:
[Gramps SuperTool script file]
version=1
[title]
SuperTool-orjson prerequisite Dashboard script
[description]
Gramps 6 adds a dependency on the orjson package.
This is not included in all linux distributions.
This SuperTool script reports if orjson is installed and fails gracefully if not.
see Discourse discussion:
https://gramps.discourse.group/t/should-there-be-an-advisory-announcement-on-6-0-6-0-1
[category]
Dashboard
[initial_statements]
try:
import orjson
test = "orjson is installed.\nYour OS is ready to be upgraded to Gramps 6"
except ImportError:
test = (
"orjson is NOT installed. \n"
"This 'Optimized Rust JSON' library is an ultra-fast, correct "
"JSON parser and serializer for Python written in Rust.\n"
"It is a prerequisite for running Gramps version 6 and newer.\n\n"
"Please use an orjson package installer during upgrade.\n\n"
"Alternately, use the Snap or Flatpak Gramps installers "
"- which include orjson.\n"
" see https://gramps.discourse.group/t/7613/17"
)
print(test)
[statements]
[filter]
[expressions]
test
[scope]
selected
[unwind_lists]
False
[commit_changes]
False
[summary_only]
True
Surely this is getting to the point of “having a man with a red flag walking in front of every automobile”
There is a limited resource called developers, there are already sufficient pointers to say if you are running Linux of whatever flavour you may! have an issue with orjson (note these issues are being addressed) to not require the average adult using GRAMPS to require this level of hand holding.
I initially had an issue with ver6.0.1 because of wanting to try it on a Raspberry Pi being in a rush involved with other things and not paying attention to the information that was already there.
phil
And what about those users like me who have removed the Dashboard as a waste of space (Deep Connections Graph excluded)
Troubleshooting tools almost always are helpful. They create confidence that users are attacking the true underlying issue, not just a symptom.
And it confirms when they have actually resolved the blocking issue. Which is better than just blindly re-installing and hoping there are not multiple contributing blockages.
I suggest that users let their package manager install dependencies during installation. In this way orphaned packages will not be left behind if Gramps is uninstalled.
If you use FlatPak or Snap packages then all required dependencies will be installed.
If you use the package manager in your distribution then all required dependencies will be installed, but you may only have an old version of Gramps in your distribution’s repository.
If you are installing Gramps from source, then you may have to install orjson from PyPI.
If you are trying to install the .deb file intended for Ubuntu 24.10 on an older version of Ubuntu then you will get an error.