netCDF-Fortran easyblock doesn't follow class encoding scheme

[boegel]

The easyblock for building netCDF-Fortran doesn't follow the encoding scheme as discussed in #86.

The class is named EB_netCDF_Fortran, while it should be EB_netCDF_dash_Fortran.

This needs to be adjusted, and the code that makes this work (i.e. that translates a - into a _) needs to be removed such that an inconsistency like this can not occur again.

[boegel]

Related: the module name for python-meep currently needs to be python_meep (not python_minus_meep like the class name that follows the encoding scheme defined in #86).

The module names should also follow the encoding scheme?

[boegel]

Class name should already be EB_netCDF_minus_Fortran, otherwise it doesn't build like it should (see #168).

Module name still doesn't follow encoding scheme though.

[fgeorgatos]

Hi,

On Wed, Sep 26, 2012 at 6:15 PM, Kenneth Hoste notifications@github.comwrote:

Class name should already be EB_netCDF_minus_Fortran, otherwise it
doesn't build like it should (see #168easybuilders/easybuild#168
).

Module name still doesn't follow encoding scheme though.

I think we never applied as much rigor for module (file)names as with the
class names,
because we treated them as containers and therefor irrelevant for requiring
encoding.

If that still holds true, just come up with something that keeps things
manageable
for most situations (think of c++, map|reduce and other funny corner cases).
point in case: How weird do you want "c++-gnome-bindings" to look like?

cheers,
Fotis

[boegel]

I guess module naming almost never an issue, except when the lower-casing that we do yields clashes. And I think we then agreed that both easyblock would just go into the same module (e.g. EB_LAPACK, EB_LaPack and EB_lapack would all go into lapack.py).

So, we just need to remove the part that replaces an - with an _, and rename any modules that follow that rule.

[boegel]

Fixed by f1a8845.

[boegel]

Ah, I just noticed why we were replacing '-' with '_' in module names.

It's illegal according to PEP8, and PyLint doesn't analyze module that have '-' in the name.

So, this will need to be revisited, although module names like python-meep.py or netcdf-fortran.py work.

[fgeorgatos]

Hi Ken,

On Tue, Oct 2, 2012 at 2:55 PM, Kenneth Hoste notifications@github.comwrote:

Ah, I just noticed why we were replacing '-' with '_' in module names.

It's illegal according to PEP8, and PyLint doesn't analyze module that
have '-' in the name.

So, this will need to be revisited, although module names like
python-meep.py or netcdf-fortran.py work.

In the name of simplicity, I suggest to replace all offending characters
with _ , eg:
c++-gnome-bindings -> c___gnome_bindings

Some packages with really funny names will end up clustering in _ __ ___
...and so on but, I think this is the price you have to pay for such
choices ;-)

While looking at "Allowable characters in directory entries",
http://en.wikipedia.org/wiki/Comparison_of_file_systems#Limits
I realize making module names FAT-compatible makes much sense.
(caveat: . becomes _ , but for a container this should be irrelevant)

[boegel]

Good suggestion @fgeorgatos, fixed by 4edffa2