@alalazo: any comments?

As it is right now this isn't super useful, but it might be more useful for naming_scheme and short_description_scheme if we exposed more of spec to them. For example, I would like to have the compiler flags in the short description.

Also note that currently this PR defaults to a package provided short description over this scheme. Does everyone agree with that default?

@tgamblin @mwilliammyers I have no objection in general on the scheme, but I was wondering if it could make sense to have something like:

modules:
  enable:
  - tcl
  - dotkit
  tcl:
    naming_scheme: '{name}/{version}_{compiler.name}-{compiler.version}'
    all:
      short_description: '{name}@{version} {compiler.name}@{compiler.version}'
    <other constraint>:
      short_description: <more-specialized-rule>

The rationale is that the naming scheme is something that must be consistent over all the modules to make sense, while a short description can be customized for different set of packages.

For the defaults : I would prefer a rule in modules.yaml over a short_description in package.py as otherwise there will be no way to override what was coded in a package (other than modifying the package itself, of course). In any case I would prompt a message to the user in case of collision between Package.short_description and a custom rule in modules.yaml. What do you think?

@alalazo Yeah I agree with you on all accounts. I hadn't thought of that. Should we prompt the user to make a decision interactively or just warn the user that we are overriding it with modules.yaml?

Personally I like warnings better than prompts, as warnings don't prevent non-interactive use. I forget when exactly I approved the ever-present warning in spack uninstall but I'm not sure I actually like it 😬.

I agree with @alalazo on modules.yaml vs. packages.yaml.

@alalazo: I was looking at short_description and wonder if it would make sense to default the short description to contain the first line of each package's docstring. That would be pythonic. We don't do it for all packages but I think it would be generally useful. See PEP 257 section on multi-line docstrings.

Should we prompt the user to make a decision interactively or just warn the user that we are overriding it with modules.yaml?

@mwilliammyers I would go for a tty.msg or a tty.debug (depending on how much verbose we want to be by default) and give the user no choice on this one 😈

Personally I like warnings better than prompts, as warnings don't prevent non-interactive use. I forget when exactly I approved the ever-present warning in spack uninstall but I'm not sure I actually like it 😬.

@tgamblin Do you mean the ever present prompt in spack uninstall ? I added that one to avoid deleting packages accidentally... but as I like non-interactive use too I added the -y option to override the behavior, so :

# Remove all installed packages that match foo and their dependents
spack uninstall -d -a foo # Asks for user confirmation
spack uninstall -d -a -y foo # Proceeds without asking

I was looking at short_description and wonder if it would make sense to default the short description to contain the first line of each package's docstring. That would be pythonic.

👍 for this

Personally I like warnings better than prompts, as warnings don't prevent non-interactive use. I forget when exactly I approved the ever-present warning in spack uninstall but I'm not sure I actually like it 😬.

@tgamblin Do you mean the ever present prompt in spack uninstall ? I added that one to avoid deleting packages accidentally... but as I like non-interactive use too I added the -y option to override the behavior, so

Yep, oops -- I mean the prompt. I like it to be non-interactive by default, though I think a preference to make it interactive (like rm -i) would be ok.

@tgamblin

@alalazo: I was looking at short_description and wonder if it would make sense to default the short description to contain the first line of each package's docstring. That would be pythonic. We don't do it for all packages but I think it would be generally useful.

I can implement the default short description behavior in #3183. Regarding customization you can already override the context dictionary both from package and modules.yaml.

@mwilliammyers I was wondering if you agree closing this PR. I am reworking module file generation in #3183 to introduce template engines and jinja2 and I think it covers the use case here.

Closing as #3183 as got this:

I was looking at short_description and wonder if it would make sense to default the short description to contain the first line of each package's docstring. That would be pythonic. We don't do it for all packages but I think it would be generally useful. See PEP 257 section on multi-line docstrings.

implemented. For instance a lua module file for metis contains:

-- -*- lua -*-
-- Module file created by spack (https://github.com/LLNL/spack) on 2017-09-20 09:26:51.800473
--
-- [email protected]%[email protected]~debug~gdb~int64~real64+shared arch=linux-ubuntu14.04-x86_64 /mknqhcy
--

whatis([[Name : metis]])
whatis([[Version : 5.1.0]])
whatis([[Short description : METIS is a set of serial programs for partitioning graphs, partitioning finite element meshes, and producing fill reducing orderings for sparse matrices. The algorithms implemented in METIS are based on the multilevel recursive-bisection, multilevel k-way, and multi-constraint partitioning schemes.]])

help([[METIS is a set of serial programs for partitioning graphs, partitioning
finite element meshes, and producing fill reducing orderings for sparse
matrices. The algorithms implemented in METIS are based on the
multilevel recursive-bisection, multilevel k-way, and multi-constraint
partitioning schemes.]])

...