Additional manifest config fields

[ewels]

It would be great to have a few new manifest config variables to help describe pipelines:

manifest {
    docsURL = "https://mypipeline.com/docs"
    iconURL = "https://mypipeline.com/icon.png"
    icon = "assets/icon.png"
    organisation = "University of Phil"
    license = "MIT"
}

[abhi18av]

Mmm, interesting suggestion Phil!

Perhaps, it should be kept open-ended like with a manifest.meta field so that other tools/plugins could possibly populate or read from that field?

P.S. "University of Phil" sounds nice! 😄

[ewels]

I don't really understand how anything could (or should) populate it, other than the pipeline developers?

Having a field for an arbitrary map of keys could be nice to have a flexible use case 👍🏻 However, standardisation is nice. We could add that in addition to (some of?) the suggested keys above.

[abhi18av]

I was just wondering that since there are some Git related fields within manifest like recurseSubmodules, defaultBranch then it might make sense to logically combine further options together through an open-ended map like

manifest {
    homePage = 'http://foo.com'
    description = 'Pipeline does this and that'

    .. existing fields...

    meta {
         documentationUrl = "https://doc.pipeline.com"
         license = "MIT" 
         researchGroup = "some specific research group"

         ...arbitrary fields ...
    }
}

Also the idea regarding open-ended metadata stems from #2723, which might result in a config which is interchangeable with the JSON format.

[ewels]

Ah ok. Following that thread, it might make sense to move all descriptive fields (including current) to a meta sub-map then?

manifest {
    defaultBranch
    recurseSubmodules
    mainScript
    name
    nextflowVersion
    version
    meta {
        author
        description
        doi
        homePage
        docsURL
        iconURL
        icon
        organisation
        license
    }
}

eg. depreciate manifest.description and manifest.doi etc, instead replacing with manifest.meta.description

[abhi18av]

Ideally it'd make sense yes, since there is specific information in those fields which is natively used by NF (git related things) and others are there only for annotating the pipeline metadata which authors could change without any crucial change in the pipeline logic itself.

However, for backward friendliness it might cause problems to remove the existing pipeline meta information. Just wanted to highlight a possible pathway here 😊

[ewels]

I think deprecating the old ones and leaving them there for a version or two is probably ok. Like you say, we hopefully have a new config coming one day anyway.. 🤷🏻‍♂️

[bentsherman]

I recommend adding the following fields based on my experience with the prov formats:

• license
• map for authors with name, affiliation, email, orcid

[ewels]

Good idea with the author map 👍🏻

[pinin4fjords]

+1, and can we have manifest.maintainer, please? To note currently responsible parties as distinct from original authors.

[jfy133]

For maintainers (and maybe others), I think the CRAN R package manifests are a good guide, particularly when it comes to author/maintainer/contributors, e.g. for dplyr:

https://cran.r-project.org/web/packages/dplyr/index.html

[pditommaso]

it makes sense to include this into manifest to have it sent to Platform. However would not make sense to call it publication (or something related) instead of a generic meta ?

[pditommaso]

Discussing this, it looks there consensus to move the new fields into manifest e.g.

manifest { 
    author
    description
    doi
    homePage
    docsUrl
    iconUrl
    icon
    organisation
    license
} 

[ewels]

Yup - adding an extra, plus some notes based on the discussion above:

manifest { 
    author     // String or an array of maps. Maps can contain orcid etc - see comment above
    maintainer // Same as above, new field
    description
    doi
    homePage
    docsUrl
    icon
    organisation
    license
} 

[Edit]: Updated to remove iconUrl

[pditommaso]

What's icon vs iconUrl ?

[pditommaso]

We talked, we can use iconUrl both for relative path and fully qualified URL

[ewels]

Should maybe call it icon, but yeah 👍🏻

[pditommaso]

@jorgee this is the class involved

nextflow/modules/nextflow/src/main/groovy/nextflow/config/Manifest.groovy

Line 1 in 62e2604

/*

[jorgee]

When running netxflow info <project_name>, some of the manifest values are printed out (at least author and description). Which ones of the new values should be printed? I think maintainer, organization and license should be printed.

[pditommaso]

That's reasonable but let's keep outside the scope of this issue.

[pditommaso]

Let's extend the author to use the following data structure

manifest {
  contributors = [ [name:'Paolo', orcid: 'xyz'], [name: 'Phil', orcid: 'xyz'] ]
}

and deprecate the current author and maintainers

The require fields are:

• name (string)
• email (string)
• affiliation (string)
• orcid (uri)
• github (uri)
• contribution (enum)

[ewels]

Rather than having both authors and maintainers, could have a single contributors with a key type that can be author / maintainer / etc.

[bentsherman]

BCO models authors and maintainers as a single list of "contributors" with a contribution type:

        "contributors": [
            {
                "name": "Charles Hadley King", 
                "affiliation": "George Washington University", 
                "email": "hadley_king@gwu.edu",
                "contribution": ["createdBy", "curatedBy"],
                "orcid": "https://orcid.org/0000-0003-1409-4549"
            },

            {
                "name": "Eric Donaldson", 
                "affiliation": "FDA", 
                "email": "Eric.Donaldson@fda.hhs.gov",
                "contribution": ["authoredBy"]
            }
        ]