post-build versioning does not work, although explicitly mentioned in the docs

[kfot]

Checklist

• I added a descriptive title
• I searched open reports and couldn't find a duplicate

What happened?

I attempted to set the package version during the post-build phase as described in the the brief paragraph from the most recent conda-build docs.

Post-build versioning: In some cases, you may not know the version, build number, or build string of the package until after it is built. In these cases, you can perform Templating with Jinja or utilize Git environment variables and Inherited environment variables.

Based on this, I assumed the environment variables or templated code would be evaluated lazily (OS is Windows). However, this did not work.

package:
  version: "{{  environ.get("PACKAGE_VERSION") }}"  # env var set post-build in the build script 
...
build:
  noarch: python
  script: {{ PYTHON }} -m pip install . --no-deps --no-build-isolation -vv && set PACKAGE_VERSION=1.2.3

The build command succeeds, but the version is set to None, indicating that the environment variable PACKAGE_VERSION is not being evaluated as expected. My experiments suggest that the version is always set before the build phase.

Conda Info

active environment : mylib
    active env location : C:\Users\kfot\scoop\apps\anaconda3\current\App\envs\mylib
            shell level : 1
       user config file : C:\Users\kfot\.condarc
 populated config files : C:\Users\kfot\.condarc
          conda version : 24.5.0
    conda-build version : 24.5.1
         python version : 3.12.4.final.0
                 solver : libmamba (default)
       virtual packages : __archspec=1=haswell
                          __conda=24.5.0=0
                          __win=0=0
       base environment : C:\Users\kfot\scoop\apps\anaconda3\current\App  (writable)
      conda av data dir : C:\Users\kfot\scoop\apps\anaconda3\current\App\etc\conda
  conda av metadata url : None
                          https://conda.anaconda.org/services/win-64
                          https://conda.anaconda.org/services/noarch
                          https://repo.anaconda.cloud/repo/main/win-64
                          https://repo.anaconda.cloud/repo/main/noarch
                          https://repo.anaconda.cloud/repo/r/win-64
                          https://repo.anaconda.cloud/repo/r/noarch
                          https://repo.anaconda.cloud/repo/msys2/win-64
                          https://repo.anaconda.cloud/repo/msys2/noarch
          package cache : C:\Users\kfot\scoop\apps\anaconda3\current\App\pkgs
                          C:\Users\kfot\.conda\pkgs
                          C:\Users\kfot\AppData\Local\conda\conda\pkgs
       envs directories : C:\Users\kfot\scoop\apps\anaconda3\current\App\envs
                          C:\Users\kfot\.conda\envs
                          C:\Users\kfot\AppData\Local\conda\conda\envs
               platform : win-64
             user-agent : conda/24.5.0 requests/2.32.2 CPython/3.12.4 Windows/10 Windows/10.0.19045 solver/libmamba conda-libmamba-solver/24.1.0 libmambapy/1.5.8 aau/0.4.4 c/. s/. e/.
          administrator : False
             netrc file : None
           offline mode : False

Conda Config

==> C:\Users\kfot\.condarc <==
auto_activate_base: False
ssl_verify: truststore
add_anaconda_token: True
channel_priority: disabled
channels:
  - services
  - defaults
default_channels:
  - https://repo.anaconda.cloud/repo/main
  - https://repo.anaconda.cloud/repo/r
  - https://repo.anaconda.cloud/repo/msys2
show_channel_urls: True
restore_free_channel: False
report_errors: False
solver: libmamba

==> envvars <==
allow_softlinks: False

Conda list

not related

Additional Context

No response

[kfot]

According to the changelog and that test, the post-build metadata manipulation is no longer supported, suggesting that the linked docs fragment might not be up to date.
By the way, does it mean that there is no way to set the version based on the data obtained during the building process (i.e. from dynamic setuptools_scm reference in pyproject.toml file?)?
Although, not directly related, implementing setuptools_scm support #4774 would be the ideal solution for me.