improve/fix multiple-output recipe

[carlodri]

Checklist

• Used a personal fork of the feedstock to propose changes
• Bumped the build number (if the version is unchanged)
• Reset the build number to 0 (if the version changed)
• Re-rendered with the latest conda-smithy (Use the phrase @conda-forge-admin, please rerender in a comment in this PR for automated rerendering)
• Ensured the license file is being packaged.

Closes #13

[conda-forge-linter]

Hi! This is the friendly automated conda-forge-linting service.

I just wanted to let you know that I linted all conda-recipes in your PR (recipe) and found it was in an excellent condition.

[carlodri]

@xhochy sorry, can you please help me and review this?

what I don't understand is

• why no tests are run for the black part of the recipe outputs...
• why the previous build worked fine on my windows machine (both black and blackd packages)

[xhochy]

Does also work locally for me, file output is:

./site-packages
./site-packages/black.py
./site-packages/blackd.py
./site-packages/_black_version.py
./site-packages/blib2to3
./site-packages/blib2to3/Grammar.txt
./site-packages/blib2to3/PatternGrammar.txt
./site-packages/blib2to3/__init__.py
./site-packages/blib2to3/pygram.py
./site-packages/blib2to3/pgen2
./site-packages/blib2to3/pgen2/token.py
./site-packages/blib2to3/pgen2/pgen.py
./site-packages/blib2to3/pgen2/__init__.py
./site-packages/blib2to3/pgen2/literals.py
./site-packages/blib2to3/pgen2/grammar.py
./site-packages/blib2to3/pgen2/conv.py
./site-packages/blib2to3/pgen2/parse.py
./site-packages/blib2to3/pgen2/driver.py
./site-packages/blib2to3/pgen2/tokenize.py
./site-packages/blib2to3/pytree.py
./site-packages/black-19.10b0.dist-info
./site-packages/black-19.10b0.dist-info/RECORD
./site-packages/black-19.10b0.dist-info/LICENSE
./site-packages/black-19.10b0.dist-info/direct_url.json
./site-packages/black-19.10b0.dist-info/WHEEL
./site-packages/black-19.10b0.dist-info/entry_points.txt
./site-packages/black-19.10b0.dist-info/top_level.txt
./site-packages/black-19.10b0.dist-info/INSTALLER
./site-packages/black-19.10b0.dist-info/METADATA
./info
./info/licenses
./info/licenses/LICENSE
./info/recipe
./info/recipe/build_base.sh
./info/recipe/conda_build_config.yaml
./info/recipe/meta.yaml
./info/recipe/meta.yaml.template
./info/paths.json
./info/hash_input.json
./info/files
./info/about.json
./info/link.json
./info/index.json
./info/git

[mbargull]

I was just about to set off all alarm bells because this would've affected a whole lot of other packages, too. We do have a truck load of recipes that do not use --no-deps because at some point conda-forge's docs didn't recomment it and conda-build is meant to set an environment variable for that.

Thankfully, this seems to affect only outputs of recipes. (Which might also be the answer to @carlodri's questions "why the previous build worked fine on my windows machine": If the previous build did not run pip install in the output/script, then it wasn't affected.)

I'm opening a conda-build issues for this.

[carlodri]

@mbargull @xhochy I'm still puzzled as to why no tests are run for the black part of the recipe outputs...

[mbargull]

My best bet is that moving test from toplevel to /outputs[0]/test could be the reason. conda-build does some special handling for outputs whose package name is the same as the toplevel package name.
Meaning, either moving test back up or renaming the toplevel to something else like black-recipe or something might fix that. For the latter (which I personally prefer) it probably makes sense to also move /build/{noarch,entry_points} to /outputs[0]/build/. Also, the blackd entrypoint should be moved to the blackd output in any case.

[mbargull]

I took a look at the build log: https://dev.azure.com/conda-forge/feedstock-builds/_build/results?buildId=187392&view=logs&j=1bf226d3-0e2f-52d8-fa93-7d9e633347b3&t=c09a5a47-eec3-5700-9284-6f1bd7b23501&l=428 and what follows does not look right. This is due to the same conda-build issue I opened.
You know what, I'll just open a PR for this feedstock with the changes I think make sense ;).

[mbargull]

xref: #15