Skip to content

Explicit path alias matching order for coverage combine #649

Closed
@nedbat

Description

@nedbat

Originally reported by Jonathan Beezley (Bitbucket: jbeezley, GitHub: jbeezley)


Over in https://github.com/girder/girder, we have a fairly convoluted use case where we need to use path aliases for our coverage combine step, but we also need ensure that the matching occurs in the correct order. To gloss over some of the messy details, the issue is that in a development install we have the following directory structure:

root/ ->
    girder/
        __init__.py
        ...
    plugins/
        __init__.py
        ...

But when installed, the package looks like this:

root/ ->
    girder/
        __init__.py
        ...
        plugins/
            __init__.py
            ...

We need to be able to combine coverage files executed from both of these environments,so we use a path alias that looks like this:

[coverage:paths]
plugins =
    plugins/
    build/test/tox/*/lib/*/site-packages/girder/plugins/
girder = 
    girder/
    build/test/tox/*/lib/*/site-packages/girder/

The issue here is that it matches the girder section first and aliases the plugin modules to $PWD/girder/plugins rather than $PWD/plugins.

Globbing patterns don't allow us to exclude only certain subdirectories from the second group, so we need to have some way to ensure that the it is matched after the first.

I would be willing to implement one of the following solutions. I would appreciate any guidance as to which approach (if any) would be preferred by the maintainers.

  1. Somehow allow explicit regex's in the path matching. I'm not sure how the syntax of this would work.
  2. Use an OrderedDict on this line so that the original order in the config file is preserved. This would be ideal, but it would require a backport of OrderedDict for python 2.6 support.
  3. Iterate through the keys in sorted order on this line. Users could then choose to name the alias targets so they apply in the required order. This is the simplest solution that I can think of, but it smells a little hacky to me.

Metadata

Metadata

Assignees

No one assigned

    Labels

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions