mark noarch/nteract-scrapbook-0.5.0-*_1 broken

[bollwyvl]

Guidelines for marking packages as broken:

• We prefer to patch the repo data (see here) instead of marking packages as broken. This alternative workflow makes environments more reproducible.
• Packages with requirements/metadata that are too strict but otherwise work are not technically broken and should not be marked as such.
• Packages with missing metadata can be marked as broken on a temporary basis but should be patched in the repo data and be marked unbroken later.
• In some cases where the number of users of a package is small or it is used by the maintainers only, we can allow packages to be marked broken more liberally.
• We (conda-forge/core) try to make a decision on these requests within 24 hours.

Checklist:

• [x] Make sure your package is in the right spot (broken/* for adding the broken label, not_broken/* for removing the broken label)
• [x] Added a description of the problem with the package in the PR description.
• [x] Added links to any relevant issues/PRs in the PR description.
• [x] Pinged the team for the package for their input.

The upstream package changed the distribution name (dropping the nteract- prefix). I added an alias package for depending on the old name, but it's causing issues for downstreams.

• added in https://github.com/conda-forge/nteract-scrapbook-feedstock/pull/6
• downstream issue reported on https://github.com/conda-forge/nteract-scrapbook-feedstock/issues/7
• fixed with https://github.com/conda-forge/nteract-scrapbook-feedstock/pull/8

@conda-forge/nteract-scrapbook

[beckermr]

Removing a package to avoid a pip check failure is not really needed.

If pip check fails, that's fine. Conda is not pip and the metadata could simply be different.

[beckermr]

The solution here is to remove pip check from the recipe of the offending feedstock. Or you can write some code to ignore certain errors.

[bollwyvl]

The problem is I (as @conda-forge/nteract-scrapbook) created a package which does not exist on pip (nteract-scrapbook 0.5.0) in the thinking that it would be easier to keep working in the future, but this is not the case. In this case, we're dealing with airflow-related stuff, which is all but impossible to test in any thorough way, and keep on top of the huge list of dependencies, which pip check at least lets us do.

I concur that having a conda-forge-specific pip check (which didn't require pip!) would be more useful in the long run... except that this metadata actually does get used at runtime by certain parts of the python (not pip) system, namely entry_points, which actually check that all of this stuff is consistent. We've encountered this on python-language-server, pytest, etc. which make significant use of that packaging feature.

[beckermr]

I don't personally find this argument convincing. I'm happy to keep chatting though.

cc @conda-forge/core for other opinions

We should be able to create a simple feedstock that holds a python script that runs pip check and then ignores some errors selectively. This tool could then be used by a lot of recipes. This is a much better solution than pulling a package simply because it got renamed on conda.