PhyloPhlAn

[fasnicar]

Replace this sentence with a detailed description of your pull request

---

Bioconda requires reviews prior to merging pull-requests (PRs). To facilitate this, once your PR is passing tests and ready to be merged, please add the please review & merge label so other members of the bioconda community can have a look at your PR and either make suggestions or merge it.

• I have read the guidelines for bioconda recipes.
• This PR adds a new recipe.
• AFAIK, this recipe is directly relevant to the biological sciences
  (otherwise, please submit to the more general purpose conda-forge channel).
• This PR updates an existing recipe.
• This PR does something else (explain below).

Everyone has access to the following BiocondaBot commands, which can be given in a comment:

• @BiocondaBot please update will cause the BiocondaBot to merge the master branch into a PR
• @BiocondaBot please add label will add the please review & merge label.
• @BiocondaBot please fetch artifacts will post links to packages and docker containers built by the CI system. You can use this to test packages locally before merging.

For members of the Bioconda project, the following command is also available:

• @BiocondaBot please merge will cause packages/containers to be uploaded and a PR merged. Someone must approve a PR first! This has the benefit of not wasting CI build time required by manually merging PRs.

If you have questions, please post them in gitter or ping @bioconda/core in a comment (if you are not able to directly ping @bioconda/core then the bot will repost your comment and enable pinging).

[marcelm]

For testing, you can temporarily skip the linter check:

extra:
  skip-lints:
    - uses_vcs_url
    - missing_hash

But the final recipe should use a proper release.

And an observation on your setup.py: The check_call looks very fragile. If you get weird failures from pip install, this could be the reason.

[fasnicar]

Thank you very much Marcel for your suggestions.
I'm gonna change the check_call() to call(). The script run there is needed to generate standard configuration files tailored for the machine where the package will be installed, but it shouldn't be blocking if none of the config files can be generated.

[marcelm]

Sorry I should have been more explicit: The problem is running something unconditionally on every setup.py invocation since it should only run when specific subcommands are run. For example, the call() will now also be done when running python3 setup.py --version. The proper way would be to customize one of the subcommands (perhaps sdist), but I guess you’re fine at the moment since it doesn’t hurt to regenerate the files. But as I said, just something to keep in mind in case you see weird failures.

[fasnicar]

Ah, I see. Thanks for the heads up, I'll check it out and update on the next release.