let's escape wherever special chars, such as ., -, +, &, ...
this trend comes straight from the 1st hackathon, whereby we escaped (somewhat) issues that can pop up due to unusual application names, so that easyblocks namespace is liberal:
https://github.com/hpcugent/easybuild-framework/blob/master/easybuild/tools/filetools.py#L71 # ref. STRING_ENCODING_CHARMAP
(ie. avoid apps namespace to be coupled with other software limits/constraints)
We see a problem of the same nature appearing as regards env. variables,
and my concern is that, alternative module implementations may give even more surprises and incompatibilities with special characters:
https://github.com/hpcugent/easybuild-easyconfigs/pull/675
Following the liberal-input-conservative-output principle
http://en.wikipedia.org/wiki/Robustness_principle
I'd propose to do the same within defined environment variables, and for the same reason!
btw. this will have the (IMHO, positive) effect of renaming
EBROOTXORGMINMACROS -> EBROOTXORG_MINUS_MACROS
The 2nd is far more readable, we could even consider format: EBROOT__XORG_MINUS_MACROS...
Hi,
let's escape wherever special chars, such as
.
,-
,+
,&
, ...this trend comes straight from the 1st hackathon, whereby we escaped (somewhat) issues that can pop up due to unusual application names, so that easyblocks namespace is liberal: https://github.com/hpcugent/easybuild-framework/blob/master/easybuild/tools/filetools.py#L71 # ref. STRING_ENCODING_CHARMAP (ie. avoid apps namespace to be coupled with other software limits/constraints)
We see a problem of the same nature appearing as regards env. variables, and my concern is that, alternative module implementations may give even more surprises and incompatibilities with special characters: https://github.com/hpcugent/easybuild-easyconfigs/pull/675
Following the liberal-input-conservative-output principle http://en.wikipedia.org/wiki/Robustness_principle I'd propose to do the same within defined environment variables, and for the same reason!
Your stance?