On Wed, Oct 16, 2024 at 08:39:30PM +0000, Smith, Justin wrote: > Traceback (most recent call last): > File "<string>", line 1, in <module> > ImportError: could not import gobject (error was: 'No module named gobject') > > This made me think that something is missing from some environment variable > because it can't find a module. However, if I change the script to instead be > `import gwyutils`, it does show a path to at least that module in the error > message:
gobject should be a prerequisite of pygtk2 and be available alongside with it. But it is a separate package. Seeing how you are putting the environment together piecewise (and definitely do not get automatically the correct chain of dependencies), it may be missing. Look for something called like pygobject2, python2-gobject, etc. > (1) warnings for various .lo files about variables being unused, > uninitialized, etc. (e.g., "In file included from oirfile.c:67: > gwyzip.h:36:19: warning: 'gwyzip_open' used but never defined") which > I assume are not relevant This is not relevant to pygwy, but still odd. It should be harmless because it occurs in a static function which is unused when you do not have any ZIP library (and I would guess it disappears in linker optimisation). But we should probably be more careful to not even compile the unused function. > and (2) seemingly more relevant feecback when > make goes into gwyddion-2.66/modules/pygwy--it gives a bunch of warnings/ > messages about not being able to write methods (I cut out a bunch of analogous > messages to make it less long): Compiling pygwy always gives a bunch of warnings about incomplete coverage of the C API. This is expected as the coverage is not 100%. Your numbers seem about right. > Libraries have been installed in: > /home/jds/miniconda3/envs/gwyd/lib/gwyddion/modules > If you ever happen to want to link against installed libraries > in a given directory, LIBDIR, you must either use libtool, and > specify the full pathname of the library, or use the '-LLIBDIR' > flag during linking and do at least one of the following:[...] It always says that when you install libraries outside of a standard/system directory. Just ignore it. Although you may need to adjust LD_LIBRARY_PATH to point to the libraries, depending. > Note that '/home/jds/miniconda3/envs/gwyd/share' is not in the search path > set by the XDG_DATA_HOME and XDG_DATA_DIRS > environment variables, so applications may not > be able to find it until you set them. The > directories currently searched are:[...] You will not get some desktop integration, but otherwise it is harmless. You can also try giving --enable-home-installation to configure and it will install the desktop integration files to $(XDG_DATA_HOME) instead of the prefix. Understand that this makes the installation no longer contained in a single directory. So I do not like it much and it may not be well tested. > ...so, I tried the following without success (I get the same error in the > Pygwy > Console and also mess up the icons in the Gwyddion navigation/tools window > (the > images are replaced with little pictures of a page with an X on it)): > > $ conda env config vars set XDG_DATA_HOME="/home/jds/miniconda3/envs/gwyd/ > share:$XDG_DATA_HOME" Definitely do not do this because XDG_DATA_HOME must be a single directory. Nothing good can happen when you put multiple directories there. Regards, Yeti _______________________________________________ Gwyddion-users mailing list Gwyddion-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/gwyddion-users
