modularity / fedmod

#67 add 'lint' command
Merged by karsten. Opened by nphilipp.
modularity/ nphilipp/fedmod master--lint-modulemd  into  master

Download 67.patch

This validates ModuleMD YAML files according to the currently published Fedora Packaging Guidelines for Modules.

rebased onto 0b2a19955ac6614ca027a7389151f2b1691962b7

@nphilipp, I would drop modulemd, just lintmd, lint-md, or simply lint.

Edited by igulina

rebased onto deb982f65bca6bacd8cb3f5e8b4822f9a692ab62

@igulina done

5 new commits added

  • add license section checks
  • reformat output a little
  • add problem_detail decorator
  • execute linter methods in order of their definition
  • check if description ends in a period

9 new commits added

  • add prerequisite decorator
  • check that description exists
  • add license section checks
  • load raw YAML dict for low-level checks
  • reformat output a little
  • add problem_detail decorator
  • execute linter methods in order of their definition
  • check if description ends in a period
  • add 'lint' command

9 new commits added

  • add prerequisite decorator
  • check that description exists
  • add license section checks
  • load raw YAML dict for low-level checks
  • reformat output a little
  • add problem_detail decorator
  • execute linter methods in order of their definition
  • check if description ends in a period
  • add 'lint' command

fedmod doesn't work at all on 2.7 (we allow the use of f-strings, so it doesn't even work on 3.5), so you don't need these.

This can be shortened to fn.lint_guidelines_url = f"{self.guidelines_base_url}#{anchor}"

For input validation, an if/raise ValueError pair is preferable to an assert statement.

assert statements are removed for python -O, so these should all be handled via a helper function, rather than an assert statement.

+1 from me - main issue I noticed is that assert shouldn't be used for actual program logic - similar to C, it may get compiled out depending on how you run Python.

I did some poking around to see if I could find a higher level baseline library to build the linting engine on, but nothing obvious stuck out at me. https://pypi.python.org/pypi/yamllint did come up as a potentially interesting option to run implicitly, though.

we allow the use of f-strings, so it doesn't even work on 3.5

We might reconsider that in order to support people who are stuck on older versions of py3k, uh, enterprise operating systems. :wink:

See above :smile:

I understood that this would be a programmer error rather than a user one, i.e. doing the input validation explicitly in the CLI before calling lint().

Good catch. Just a pity that this will add more parentheses... :wink:

rebased onto 146d97d293c2d1870846f6267b57243e1d6901da

The latest rebase adds the --min-level option and validates the user input before passing it into linter.lint(...).

12 new commits added

  • add --min-level option
  • use check*() methods rather than assert
  • add prerequisite decorator
  • check that description exists
  • add license section checks
  • load raw YAML dict for low-level checks
  • reformat output a little
  • add problem_detail decorator
  • execute linter methods in order of their definition
  • check if description ends in a period
  • add 'lint' command
  • don't import from future

1 new commit added

  • use click.Choice for validating --min-level

3 new commits added

  • flag fields which should be set during build
  • mention recognized license keys
  • format guideline blurbs and problem details better

16 new commits added

  • flag fields which should be set during build
  • mention recognized license keys
  • format guideline blurbs and problem details better
  • use click.Choice for validating --min-level
  • add --min-level option
  • use check*() methods rather than assert
  • add prerequisite decorator
  • check that description exists
  • add license section checks
  • load raw YAML dict for low-level checks
  • reformat output a little
  • add problem_detail decorator
  • execute linter methods in order of their definition
  • check if description ends in a period
  • add 'lint' command
  • don't import from future

1 new commit added

  • add checks for the dependencies section

21 new commits added

  • check that a potential 'xmd' block is a dict
  • don't use modulemd for linting
  • add check_is_dict() and use it
  • add check_is_scalar() method and use it
  • add checks for the dependencies block
  • flag fields which should be set during build
  • mention recognized license keys
  • format guideline blurbs and problem details better
  • use click.Choice for validating --min-level
  • add --min-level option
  • use check*() methods rather than assert
  • add prerequisite decorator
  • check that description exists
  • add license block checks
  • load raw YAML dict for low-level checks
  • reformat output a little
  • add problem_detail decorator
  • execute linter methods in order of their definition
  • check if description ends in a period
  • add 'lint' command
  • don't import from future

In relation to the minimum Python version: targeting 3.6 is based on the fact that Fedora 26+ is on 3.6, and that latest RHSCL release means 3.6 is also available in supported form for RHEL 7, and in community form for CentOS 7 at https://www.softwarecollections.org/en/scls/rhscl/rh-python36/

So if we're going to require an SCL (or equivalent) on EL 7, it may as well be the latest one :)

31 new commits added

  • check the API
  • add check_is_list() and use it
  • check the profiles
  • check the references
  • check that all license elements are scalars
  • check that all license blocks are lists in one go
  • warn about unknown license keys/blocks
  • let check_is_(dict|scalar) accept multiple values
  • make assertion errors more informative
  • assert that every linter method has a docstring
  • check that a potential 'xmd' block is a dict
  • don't use modulemd for linting
  • add check_is_dict() and use it
  • add check_is_scalar() method and use it
  • add checks for the dependencies block
  • flag fields which should be set during build
  • mention recognized license keys
  • format guideline blurbs and problem details better
  • use click.Choice for validating --min-level
  • add --min-level option
  • use check*() methods rather than assert
  • add prerequisite decorator
  • check that description exists
  • add license block checks
  • load raw YAML dict for low-level checks
  • reformat output a little
  • add detail decorator
  • execute linter methods in order of their definition
  • check if description ends in a period
  • add 'lint' command
  • don't import from future

32 new commits added

  • check filters
  • check the API
  • add check_is_list() and use it
  • check the profiles
  • check the references
  • check that all license elements are scalars
  • check that all license blocks are lists in one go
  • warn about unknown license keys/blocks
  • let check_is_(dict|scalar) accept multiple values
  • make assertion errors more informative
  • assert that every linter method has a docstring
  • check that a potential 'xmd' block is a dict
  • don't use modulemd for linting
  • add check_is_dict() and use it
  • add check_is_scalar() method and use it
  • add checks for the dependencies block
  • flag fields which should be set during build
  • mention recognized license keys
  • format guideline blurbs and problem details better
  • use click.Choice for validating --min-level
  • add --min-level option
  • use check*() methods rather than assert
  • add prerequisite decorator
  • check that description exists
  • add license block checks
  • load raw YAML dict for low-level checks
  • reformat output a little
  • add detail decorator
  • execute linter methods in order of their definition
  • check if description ends in a period
  • add 'lint' command
  • don't import from future

3 new commits added

  • more comments
  • check types of content components' metadata
  • check components

6 new commits added

  • add checks for optional blocks
  • load and process the file in linter methods
  • allow empty guidelines link
  • add @prerequisite_for decorator
  • add @option decorator
  • add license blurb

2 new commits added

  • we don't really support UTF-16 at the moment
  • return a non-zero exit code on warnings, errors

1 new commit added

  • fix PyYAML dependency

2 new commits added

  • check for optional dependencies/(build)requires
  • fix some method/prerequisite names

using filter: {} gives a traceback instead of stating that filter requires a list (even if empty)

having

modules: {}

after the component rpm list causes lint to print out "One or more 'components' block is empty"

3 new commits added

  • improve wording in some detailed descriptions
  • fix grammar
  • check that filter/rpms exists before accessing it

One more corner case:
filters: ~
gives a traceback.

Is
buildrequires: ~ or
requires: ~
valid to state that there are no requirements ? lint doesn't accept that.

1 new commit added

  • don't trip over 'filter: ~'

LGTM now

1 new commit added

  • allow marking blocks as "explicitly empty"

Pull-Request has been merged by karsten

Thanks for the review!
Metadata
None
No Tags
Static archive. pagure.io was sunset in 2026; this is a read-only snapshot.
Red Hat Logo

Fedora is sponsored by Red Hat. Learn more about the relationship between Red Hat and Fedora »

© Red Hat, Inc. and others.