GNOME Bugzilla – Bug 710871
Python site-packages not found when not installed to default location using --prefix=...
Last modified: 2018-06-29 23:20:30 UTC
I compile GnuCash 2.5 with --prefix=$HOME/progs/gnucash-master --enable-python ... On running I get: Traceback (most recent call last):
+ Trace 232667
from gnucash import *
from gnucash_core import *
import gnucash_core_c
_gnucash_core_c = swig_import_helper()
_mod = imp.load_module('_gnucash_core_c', fp, pathname, description)
This is because I also have the Fedora repo GnuCash installed too, which is the version I use do my accounts. Which means, I guess, that the path to $HOME/progs/gnucash-master/lib/python2.7/site-packages isn't being set properly and gnucash is trying to load the wrong site-packages.
Created attachment 258099 [details] [review] Patch to add correct PYTHONPATH Before I commit I'd like to check if this the correct fix and also should it be backported to 2.4?
It's as good a fix as any. The alternative is fixing sys.path when starting Python, but I don't see any advantage to that over modifying environment.in. This won't work on OSX in GC2.4 because until the GSettings conversion OSX didn't read environment.
Committed r23328
I am too late to post a review as you already applied it. (I mentioned this on IRC as well). Anyways, the way it is committed has a minor bug in it: the way it's added now you will force the com. To evaluate the existing PYTHONPATH at runtime you should remove the $ sign. The {} are left alone at compile time, but expanded into the value of the corresponding environment variable at runtime. Additionally would it make sense to only set the python path if gnucash was built with the optional python support ?
I have run GnuCash a couple of times with this patch enabled. But the error doesn't go away. I think this is because I'm on a 64bit system. The path to my python modules is ${prefix}/lib64/python2.7/site-packages. But this may be something weird with building on 64bit. The gnucash shared libraries all end up in $(prefix)/lib (same as {SYS_LIB} in your patch), yet the python bindings are stored in $(prefix)/lib64... I'll see if I can sort that part out.
(In reply to comment #4) > I am too late to post a review as you already applied it. (I mentioned this on > IRC as well). > > Anyways, the way it is committed has a minor bug in it: the way it's added now > you will force the com. To evaluate the existing PYTHONPATH at runtime you > should remove the $ sign. The {} are left alone at compile time, but expanded > into the value of the corresponding environment variable at runtime. OK, fixed. Committed r23338 > > Additionally would it make sense to only set the python path if gnucash was > built with the optional python support ? Probably would, but I have no idea how to do that. I'll keep this bug open while I look into it.
Mid air collision detected! Thanks Geert. I only considered my system when writing the patch and forgot about 64 bit systems.
(In reply to comment #6) > (In reply to comment #4) > > > > Additionally would it make sense to only set the python path if gnucash was > > built with the optional python support ? > > Probably would, but I have no idea how to do that. I'll keep this bug open > while I look into it. The way to do this is to add the python path additions via an echo command in the Makefile, on condition that with-python is enabled. You could take the XDG_DATA_DIRS and GNC_DBD_DIR additions as an example.
(In reply to comment #7) > Mid air collision detected! > > Thanks Geert. I only considered my system when writing the patch and forgot > about 64 bit systems. Well, what you did should have worked on 64bit as well IMO. The 64bit bug is higher up the build system, but I lack the knowledge as well to fix this.
Created attachment 258176 [details] [review] Patch to add correct PYTHONPATH if --enable-python Another patch for review.
Comment on attachment 258176 [details] [review] Patch to add correct PYTHONPATH if --enable-python Mike, This is coming close :) A couple of remarks still: 1. your test seems a bit odd. Are you sure that ${PYTHON} will be set to the string "none" when python bindings are disabled ? I would rather use the AutoMake parameter WITH_PYTHON to check wether python bindings were enabled or not. This allows for the very simple automake syntax: if WITH_PYTHON <do something> endif 2. Next I would only amend the python path if our installation path is different from the system path. For python it appears this can easily be checked: automake sets two variables if configured with --with-python: PYTHON_SITE_PKG (path to system's python packages) pyexec_dir (path to python bindings for this build) So inside the automake if from above, you can test if these variables are different, and only then amend the PYTHONPATH. 3. Your patch assumes python is 2.7. However we support python starting from 2.4. Instead of reconstructing the site-packages path, you can use pyexec_dir mentioned above. 4. And lastly a nitpick: instead of commenting the previous line in environment.in, it's better to remove it. Also the explanation line that's still there can better be written by the makefile as well, because we only override the path if --enable-python was set. Thanks for making this work !
THanks Geert I was just looking at it again this morning and was about to reject my own patch anyway. Q: What does the variable pythondir = in src/bin/Makefile? Mine is set to ${prefix}/lib/python2.7/site-packages, is yours lib64? If it is then I can that to set the path. 1. Agree. 2. 3. Agree. See my question above. 4. Thought I had deleted the line, oops. :\
pythondir = ${prefix}/lib/python2.7/site-packages So not lib64. The one that seems to be right is this one: pyexecdir = ${exec_prefix}/lib64/python2.7/site-packages This is where gnucash installs the python bindings.
Created attachment 258220 [details] [review] Potential bug fix. Another attempt at setting the PYTHONPATH. I would have liked to have nested the "if WITH_PYTHON" block inside the previous if block but that doesn't seem to work, so it has to check again if it's being installed in the default location. This should work on 64bit systems too, but I don't have one to test this on.
Mike, I'm not sure why you are testing on datadir. These don't have anything to do with PYTHON. How about comparing PYTHON_SITE_PKG against pyexec_dir to test if the installation path of the python-bindings for this build environment differs from the systemwide used python site packages ?
(In reply to comment #15) > Mike, I'm not sure why you are testing on datadir. > Because I don't know enough about the GnuCash configure/build process to know any better. :) > These don't have anything to do with PYTHON. How about comparing > PYTHON_SITE_PKG against pyexec_dir to test if the installation path of the > python-bindings for this build environment differs from the systemwide used > python site packages ? OK. Thanks Geert. Learning as I go.
Created attachment 263109 [details] [review] Patch to add correct PYTHONPATH if --enable-python OK. Another try. Needs testing on 64 bit machine.
Comment on attachment 263109 [details] [review] Patch to add correct PYTHONPATH if --enable-python Works perfectly on my fedora 19 (64bit) system. The only thing I would do is remove the line with the single tab character between "fi" and "if WITH_PHTYON". The line with a tab is technically correct, but confusing. Empty lines in makefiles usually mean you start another makefile object. Otherwise good to go. Thanks !
Committed as r23465
GnuCash bug tracking has moved to a new Bugzilla host. This bug has been copied to https://bugs.gnucash.org/show_bug.cgi?id=710871. Please update any external references or bookmarks.