boost v1.83.0

[regro-cf-autotick-bot]

It is very likely that the current package version for this feedstock is out of date.

Checklist before merging this PR:

• [ ] Dependencies have been updated if changed: see upstream
• [ ] Tests have passed
• [ ] Updated license if changed and license_file is packaged

Information about this PR:

1. Feel free to push to the bot's branch to update this PR if needed.
2. The bot will almost always only open one PR per version.
3. The bot will stop issuing PRs if more than 3 version bump PRs generated by the bot are open. If you don't want to package a particular version please close the PR.
4. If you want these PRs to be merged automatically, make an issue with code>@conda-forge-admin,</codeplease add bot automerge in the title and merge the resulting PR. This command will add our bot automerge feature to your feedstock.
5. If this PR was opened in error or needs to be updated please add the bot-rerun label to this PR. The bot will close this PR and schedule another one. If you do not have permissions to add this label, you can use the phrase code>@<space/conda-forge-admin, please rerun bot in a PR comment to have the conda-forge-admin add it for you.

Pending Dependency Version Updates

Here is a list of all the pending dependency version updates for this repo. Please double check all dependencies before merging.

Name	Upstream Version	Current Version
boost	1.83.0
icu	2023-09-25

Dependency Analysis

Please note that this analysis is highly experimental. The aim here is to make maintenance easier by inspecting the package's dependencies. Importantly this analysis does not support optional dependencies, please double check those before making changes. If you do not want hinting of this kind ever please add bot: inspection: false to your conda-forge.yml. If you encounter issues with this feature please ping the bot team conda-forge/bot.

Analysis by source code inspection shows a discrepancy between it and the the package's stated requirements in the meta.yaml.

Packages found by source code inspection but not in the meta.yaml:

• docutils
• pandas
• perf
• matplotlib
• fast-histogram
• preprocess
• beautifulsoup4
• arm_pyart
• conan
• requests

Packages found in the meta.yaml but not found by source code inspection:

• libboost-devel
• libboost-python-devel
• libboost
• libboost-headers
• libboost-python

_{This PR was created by the regro-cf-autotick-bot. The regro-cf-autotick-bot is a service to automatically track the dependency graph, migrate packages, and propose package version updates for conda-forge. Feel free to drop us a line if there are any issues! This PR was generated by https://github.com/regro/cf-scripts/actions/runs/6323799417, please use this URL for debugging.}

[conda-forge-webservices[bot]]

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.

[sdebionne]

It looks like this commit did not make it to v1.83.

https://github.com/boostorg/test/commit/cada8c11df0ee360c2a05b0f44daeae6893419e4

~I'll push a patch to the bot branch to fix that.~

ERROR: Permission to regro-cf-autotick-bot/boost-feedstock.git denied to sdebionne.

I guess only maintainers can do that. Here's the 0001-Add-missing-Boost.Test-patch.patch to apply on the bot branch.

[sdebionne]

@h-vetinari I don't have permission to push the patch to the bot branch, it's attached to my previous comment if you could push it...

[h-vetinari]

Thanks for digging this up @sdebionne!

Your patch didn't apply because boost/test is only a submodule, but I cleaned up the commit a bit and it passed that compilation stage.

I think we'll want to wait a bit with 1.83 though, to keep it as a backup if the migration for 1.82 runs into any kind of trouble that requires infrastructural changes to fix (see also here).

[sdebionne]

Your patch didn't apply because boost/test is only a submodule, but I cleaned up the commit a bit and it passed that compilation stage.

Oh, right, sorry. I lazily git format-patch the original commit but of course it would not apply on the superproject / tarball. Thank you for fixing this.

I think we'll want to wait a bit with 1.83 though

There are C++ project only (like mine) that would need the latest boost ASAP (not the python binding part) independently of the conda-forge migration. Also dependent boost packages such as libboost-mpi cannot be update until this is merged.

[h-vetinari]

There are C++ project only (like mine) that would need the latest boost ASAP (not the python binding part) independently of the conda-forge migration.

I understand, but it makes sense to give this a bit more time to get the setup right (as we figure out issue throughout the migration, most of course in the initial stages), instead of having to fix this twice (main & a support branch).

[h-vetinari]

@conda-forge/boost, IMO the fixes to 1.82 that trickled in due to the gathered experience during the migration have come to a halt, and it'd be OK to merge 1.83 now. I'd like to drop the compatibility outputs for the old names already with this version, as anyone who opts into using versions that are not our default should be more than capable of adapting the name.

I'm planning to create a v1.82.x branch (conformant to the existing pattern) based on what's currently in main as soon as we merge this.

Thoughts?

[isuruf]

No, let's keep the compatibility outputs for longer. There's no reason to drop them so quickly.

[h-vetinari]

If we keep migrating for boost 1.{x mod 4}, then that's roughly 1.5 years for getting rid of usage of the old output names, which is already a very long time[^1]. You said in #164 that we shouldn't keep tech debt around forever, so extending this to 3 years does not seem reasonable to me.

In particular, we can switch on a linting rule as soon as we wrap up the 1.82 migration, so there's no issue with communicating this to (maintained) feedstocks.

If you have some concrete scenarios where the compat outputs still make a difference, could you please specify them?

[^1]: And if someone wants to be an early adopter for >1.82, i.e. stuff outside our global pinning, I see no reason why they cannot change.

[sdebionne]

Boost 1.84 is just around the corner...

[h-vetinari]

Boost 1.84 is just around the corner...

Doesn't mean we can't build 1.83. 🙃

Since there was resistance to remove the compat outputs (but no further elaboration why...), I've just gone ahead and removed that change now. In it goes...