Create a broken list for myproxyclient

[cofinoa]

Marking no-noarch packages as broken for myproxyclient version 2.1.0

The myproxyclient version it's a python noarch package.
This PR is requesting to remove those tarball that are not noarch.

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:

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

[xhochy]

Why are they broken? They look fine and you didn't link an actual issue.

[cofinoa]

The recipe it's Python noarch and I would like to remove all non-noarch builds for version 2.1.0. I create a build number 2, for this purpose but still non-noarch (build number 1) are selected by default when it's installed.

I have tried to patch but It's no clear how to proceed.

Any suggestion are more than welcome.

[chrisburr]

What was the reason for conda-forge/myproxyclient-feedstock#18?

[cofinoa]

Yes. Sorry, I didn't mention.

The conda-forge/myproxyclient-feedstock#18 it's a new build as noarch package (number=2).

[chrisburr]

Sorry I wasn't clear enough in my question, what was the original reason for trying to remove noarch and then add it back again?

(Mostly asking for my own curiosity and to better understand where conda-forge maintainers have issues)

[cofinoa]

@chrisburr It was my fault of experience on how the publish process works on conda-forge, and conda packages priority it's been handle.

I have had created the new version (2.1.0) as noarch, because previous versions were created as non-noarch, but the Python package itself it's noarch.

After successfully push the noarch new version (build=0) to the cf channel, I have had tried install it on my local machine, but only the old versions (non-noarch) were offered to be installed.

I made the assumption of that it was a problem with the priority channel resolution, which prioritize non-noarch packages over noarch packages, when no specific version it's been specified. Therefore a create a new build (build=1), but with non-noarch option.

The assumption was wrong, because there is a delay, between the push to the Anaconda channel and when it's available as install package on your local computer.

Then I have re-create again the noarch build (build=2) but now the install only offers to me the new version, but build=1 as non-noarch.

Hope this clarify my issues.

[cofinoa]

@conda-forge/core please review.