Hello Kenneth, I found it irritating because before I had not defined a sanity check (because it took care of that itself) and now I am forced to define a sanity check to correct a too strict sanity check. I think a sanity check should be rather opt-in and not (forced) opt-out (if this makes somehow sense in this context). It took me some time to figure out what went wrong, and I assume that other will experience that as well. So yes, I think your suggestion would be a good solution!
Oliver -- Oliver Stolpe Bioinformatics Core Unit Berlin Institute of Health Phone: +49 30 450 543605 Luisenstr. 56, 10117 Berlin, Germany ________________________________ From: [email protected] [[email protected]] on behalf of Kenneth Hoste [[email protected]] Sent: Thursday, November 19, 2015 5:32 AM To: [email protected] Subject: Re: [easybuild] Sanity check in python lib installation Hi Oliver, On 18/11/15 15:46, Stolpe, Oliver wrote: Hello list, I have some homegrown recipes that are installing python modules. They used to work with EasyBuild v2.1.0, but since the new releases of EasyBuild they can't pass the sanity check. In one of the releases since EasyBuild v2.1.0, we fixed an issue with the sanity check not being properly performed, particularly for extensions (like Python packages). They search for a bin directory, but some python libs simply don't have any. Right now, I am overriding it by setting sanity_check_paths = { 'files': [], 'dirs': [('lib', 'lib64')] } Is there a more elegant way to do this? I'm not sure what so non-elegant about this... Maybe you feel it's not specific enough? EasyBuild will already perform a sanity check in the sense that it will check whether "python -c 'import foo'" works (with 'foo' being a module name provided by that package). You're right that we're not enforcing that sanity_check_paths is also defined for Python packages, which was not the case before (which was considered a bug, see https://github.com/hpcugent/easybuild-framework/pull/1366. If you find this really annoying, we can define a default sanity_check_paths in the generic PythonPackage easyblock to only check for lib or lib64 (not bin). That makes sense, and can avoid that easyconfigs for Python packages include a rather silly sanity_check_paths as the one you mentioned. If sanity_check_paths are defined in the easyconfigs, they will still take the upper hand, so this would be a backwards-compatible change. regards, Kenneth Thanks, Oliver == 2015-11-18 13:09:33,267 runpy.PythonPackage INFO Using default sanity check paths: {'files': [], 'dirs': ['bin', ('lib', 'lib64')]} == 2015-11-18 13:09:33,267 runpy.PythonPackage INFO Using specified sanity check commands: [] == 2015-11-18 13:09:33,267 runpy.PythonPackage WARNING Sanity check: no (non-empty) directory of ('bin',) in /tools/easybuild/software/pysam/0.8.3-foss-2015a-Python-2.7.9 == 2015-11-18 13:09:33,268 runpy.filetools INFO Creating directory /tmp/eb-3586qK/tmpkQnTbE/all/pysam (parents: True, set_gid: False, sticky: False) == 2015-11-18 13:09:33,269 runpy.PythonPackage INFO Module file /tmp/eb-3586qK/tmpkQnTbE/all/pysam/0.8.3-foss-2015a-Python-2.7.9 written: #%Module [......] == sanity checking... == FAILED: Installation ended unsuccessfully (build directory: /tools/easybuild/build/pysam/0.8.3/foss-2015a-Python-2.7.9): build failed (first 300 chars): Sanity check failed: no (non-empty) directory of ('bin',) in /tools/easybuild/software/pysam/0.8.3-foss-2015a-Python-2.7.9 == Results of the build can be found in the log file /tmp/eb-3586qK/easybuild-pysam-0.8.3-20151118.130659.LjfHr.log ERROR: Build of /tools/easybuild.local/easyconfigs/p/pysam/pysam-0.8.3-foss-2015a-Python-2.7.9.eb failed (err: "build failed (first 300 chars): Sanity check failed: no (non-empty) directory of ('bin',) in /tools/easybuild/software/pysam/0.8.3-foss-2015a-Python-2.7.9") -- Oliver Stolpe Bioinformatics Core Unit Berlin Institute of Health Phone: +49 30 450 543605 Luisenstr. 56, 10117 Berlin, Germany
