Bump version to 2020.10

[bkpoon]

Checklist

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

Bot is down (https://github.com/conda-forge/status/issues/97), so manually creating the pull request.

[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.

[bkpoon]

@conda-forge-admin please rerender

[Anthchirp]

Since I'm not a maintainer I can't write to incoming pull requests.

Could you add

  commands:
    - pip check
  requires:
    - pip

to the test section of both outputs in the recipe please,

set +e

to the top of build.sh,

and bld.bat needs

if errorlevel 1 exit 1

following every line that isn't explicitly allowed to fail

[bkpoon]

Since I'm not a maintainer I can't write to incoming pull requests.

As was discussed in the cctbx management meeting, you can submit pull requests if you want to make changes that can fix build errors.

Can you describe what pip check would be testing? The documentation seems to say that it is for checking dependencies. There is no setup.py file in this recipe so pip check would probably be checking that the other packages (with setup.py definitions) in the environment are consistent. I do not think pip check would be checking the package that is being built.

As for set -e and if errorlevel 1 exit 1, they can be added since they would be helpful for debugging build errors.

[Anthchirp]

That's fine. I mistakenly went away from that meeting with the impression that you preferred not to do build number releases. I'll put in a PR with answers after this is merged.

[bkpoon]

Well, let's have a balance and not have too many builds per release. The debugging changes are fine, the pip check needs more explanation. Any changes to how the conda package runs will probably need discussion upstream and approval from cctbx management.

I'm going to try go get some migration bots to update cctbx-base so there will be a few commits before merging.

[Anthchirp]

Okay, here's the -v:

pip check ensures the resulting python package environment is consistent. I don't expect this to highlight any issues here and now, but it would be useful to run this test to ensure it stays this way. This is independent of whether or not the package is installed with a setup.py. I would argue it's even more important here since we bypass the setup mechanism via the preserve_egg_dir flag.

Generally, if the run environment is inconsistent you will not notice in the package itself, but you will in package builds that depend on this package. For example, I recently updated the easybuild-framework package, and the build failed because a depencendy package, archspec, created an inconsistent environment. This which would have been caught if archspec had run a pip check test. This is now part of the recommended standard python recipe, and I'm adding this to all conda-forge packages as I go along.

[bkpoon]

Sure, if pip check helps ensure consistent environments for conda-forge, I think that is fine. But the preserve_egg_dir flag is for the pytest-randomly entry point. I do not think pip check will verify entry points.