After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 710871 - Python site-packages not found when not installed to default location using --prefix=...
Python site-packages not found when not installed to default location using -...
Status: RESOLVED FIXED
Product: GnuCash
Classification: Other
Component: Python Bindings
2.5.x
Other Linux
: Normal normal
: ---
Assigned To: Mike Evans
gnucash-core-maint
Depends on:
Blocks:
 
 
Reported: 2013-10-25 11:59 UTC by Mike Evans
Modified: 2018-06-29 23:20 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
Patch to add correct PYTHONPATH (490 bytes, patch)
2013-10-25 12:04 UTC, Mike Evans
accepted-commit_now Details | Review
Patch to add correct PYTHONPATH if --enable-python (1.19 KB, patch)
2013-10-26 13:51 UTC, Mike Evans
needs-work Details | Review
Potential bug fix. (696 bytes, patch)
2013-10-27 15:06 UTC, Mike Evans
none Details | Review
Patch to add correct PYTHONPATH if --enable-python (641 bytes, patch)
2013-11-29 12:04 UTC, Mike Evans
accepted-commit_now Details | Review

Description Mike Evans 2013-10-25 11:59:11 UTC
I compile GnuCash 2.5 with --prefix=$HOME/progs/gnucash-master --enable-python ...

On running I get:
Traceback (most recent call last):
  • File "/home/mikee/progs/gnucash-master/share/gnucash/python/init.py", line 3 in <module>
    from gnucash import *
  • File "/usr/lib/python2.7/site-packages/gnucash/__init__.py", line 6 in <module>
    from gnucash_core import *
  • File "/usr/lib/python2.7/site-packages/gnucash/gnucash_core.py", line 31 in <module>
    import gnucash_core_c
  • File "/usr/lib/python2.7/site-packages/gnucash/gnucash_core_c.py", line 25 in <module>
    _gnucash_core_c = swig_import_helper()
  • File "/usr/lib/python2.7/site-packages/gnucash/gnucash_core_c.py", line 21 in swig_import_helper
    _mod = imp.load_module('_gnucash_core_c', fp, pathname, description)
ImportError: /usr/lib/python2.7/site-packages/gnucash/_gnucash_core_c.so: undefined symbol: gnc_account_get_start_cleared_balance

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.
Comment 1 Mike Evans 2013-10-25 12:04:30 UTC
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?
Comment 2 John Ralls 2013-10-25 14:38:16 UTC
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.
Comment 3 Mike Evans 2013-10-25 15:26:08 UTC
Committed r23328
Comment 4 Geert Janssens 2013-10-25 17:33:12 UTC
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 ?
Comment 5 Geert Janssens 2013-10-26 09:22:30 UTC
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.
Comment 6 Mike Evans 2013-10-26 10:06:44 UTC
(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.
Comment 7 Mike Evans 2013-10-26 10:09:08 UTC
Mid air collision detected!

Thanks Geert.  I only considered my system when writing the patch and forgot about 64 bit systems.
Comment 8 Geert Janssens 2013-10-26 10:29:51 UTC
(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.
Comment 9 Geert Janssens 2013-10-26 10:31:06 UTC
(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.
Comment 10 Mike Evans 2013-10-26 13:51:37 UTC
Created attachment 258176 [details] [review]
Patch to add correct  PYTHONPATH if --enable-python

Another patch for review.
Comment 11 Geert Janssens 2013-10-27 09:28:58 UTC
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 !
Comment 12 Mike Evans 2013-10-27 09:38:15 UTC
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.  :\
Comment 13 Geert Janssens 2013-10-27 13:59:59 UTC
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.
Comment 14 Mike Evans 2013-10-27 15:06:35 UTC
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.
Comment 15 Geert Janssens 2013-10-27 15:22:56 UTC
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 ?
Comment 16 Mike Evans 2013-10-27 15:38:22 UTC
(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.
Comment 17 Mike Evans 2013-11-29 12:04:23 UTC
Created attachment 263109 [details] [review]
Patch to add correct  PYTHONPATH if --enable-python

OK.  Another try.  Needs testing on 64 bit machine.
Comment 18 Geert Janssens 2013-11-30 14:20:41 UTC
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 !
Comment 19 Mike Evans 2013-11-30 16:05:14 UTC
Committed as r23465
Comment 20 John Ralls 2018-06-29 23:20:30 UTC
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.