Last two releases for 4.x are not present when installing for Python 3.7

[kevin-bates]

Solution to issue cannot be found in the documentation.

• [X] I checked the documentation.

Issue

When attempting to install into a conda env that uses Python 3.7, jupyter_core 4.11.1 is installed when both 4.11.2 (#54) and 4.12 (#59) should exist since their corresponding pull requests were merged.

Here's the list of packages to be installed when running conda install jupyter_core -c conda-forge within an env using Python 3.7:

  Package         Version  Build           Channel                  Size
──────────────────────────────────────────────────────────────────────────
  Install:
──────────────────────────────────────────────────────────────────────────

  + jupyter_core   4.11.1  py37hf985489_0  conda-forge/osx-64       83kB
  + python_abi        3.7  3_cp37m         conda-forge/osx-64        6kB
  + traitlets       5.8.0  pyhd8ed1ab_0    conda-forge/noarch     Cached

  Summary:

  Install: 3 packages

  Total download: 89kB

──────────────────────────────────────────────────────────────────────────

Confirm changes: [Y/n] 

I'm not sure how to go about tracking down where the disconnect might be, but I'd expect all 4.x releases to be present relative to Python 3.7.

This presents problems for downstream applications that have pinned a floor for jupyter_core to 4.11.2 and users need Python 3.7.

Installed packages

Prior to the installation, `conda list` produces:

$ conda list
# packages in environment at /opt/miniconda3/envs/elyra3.7:
#
# Name                    Version                   Build  Channel
ca-certificates           2022.12.7            h033912b_0    conda-forge
libcxx                    14.0.6               hccf4f1f_0    conda-forge
libffi                    3.4.2                h0d85af4_5    conda-forge
libsqlite                 3.40.0               ha978bb4_0    conda-forge
libzlib                   1.2.13               hfd90126_4    conda-forge
ncurses                   6.3                  h96cf925_1    conda-forge
openssl                   3.0.7                hfd90126_1    conda-forge
pip                       22.3.1             pyhd8ed1ab_0    conda-forge
python                    3.7.12          hf3644f1_100_cpython    conda-forge
readline                  8.1.2                h3899abd_0    conda-forge
setuptools                65.6.3             pyhd8ed1ab_0    conda-forge
sqlite                    3.40.0               h9ae0607_0    conda-forge
tk                        8.6.12               h5dbffcc_0    conda-forge
wheel                     0.38.4             pyhd8ed1ab_0    conda-forge
xz                        5.2.6                h775f41a_0    conda-forge

### Environment info

```shell
conda info...

     active environment : elyra3.7
    active env location : /opt/miniconda3/envs/elyra3.7
            shell level : 1
       user config file : /Users/kbates/.condarc
 populated config files : /Users/kbates/.condarc
          conda version : 4.13.0
    conda-build version : not installed
         python version : 3.9.13.final.0
       virtual packages : __osx=13.0.1=0
                          __unix=0=0
                          __archspec=1=x86_64
       base environment : /opt/miniconda3  (writable)
      conda av data dir : /opt/miniconda3/etc/conda
  conda av metadata url : None
           channel URLs : https://conda.anaconda.org/conda-forge/osx-64
                          https://conda.anaconda.org/conda-forge/noarch
                          https://conda.anaconda.org/docker/osx-64
                          https://conda.anaconda.org/docker/noarch
                          https://repo.anaconda.com/pkgs/main/osx-64
                          https://repo.anaconda.com/pkgs/main/noarch
                          https://repo.anaconda.com/pkgs/r/osx-64
                          https://repo.anaconda.com/pkgs/r/noarch
          package cache : /opt/miniconda3/pkgs
                          /Users/kbates/.conda/pkgs
       envs directories : /opt/miniconda3/envs
                          /Users/kbates/.conda/envs
               platform : osx-64
             user-agent : conda/4.13.0 requests/2.28.0 CPython/3.9.13 Darwin/22.1.0 OSX/13.0.1
                UID:GID : 501:20
             netrc file : None
           offline mode : False

[bollwyvl]

upstream, jupyter_core 5 is python 3.8+, so we do the same on this feedstock.

[bollwyvl]

Ah, this was about 4. Looking.

[bollwyvl]

Ah, this was a conda-forge-level change.

It may be theoretically possible to get it back with some hacks, but it probably falls into the category of gotta-build-it-yourself.

[bollwyvl]

If we could get #44 to work, this would not be a problem (and we'd do many, many fewer builds).

[kevin-bates]

Thanks for taking a look at this @bollwyvl. I apologize for not catching conda-forge's drop of 3.7 - I guess I had figured conda-forge, if anything, would honor the EOL date of Python versions.

Given #44 has been open for some time, along with your comments, adding these two releases seem more effort than they're worth and I don't believe folks would miss much falling back to 4.11.1 - so it's probably best I decrease the floor that I had incorrectly set (given there wasn't a 3.7 version on conda) in the first place.

Interestingly, I'm also not finding tags relative to 4.11.2 and 4.12 in the repo either and was wondering if commit hashes are captured in released modules so one could determine the "tag commit" from a given installation. Looking at the logs I don't think there was much in these releases other than various pre-commit-ci bot PRs.

At any rate, I think it's best to pursue the noarch PR on our own timeline and close this for now. If you feel otherwise, please reopen. I'm going to decrease the floor where this is affecting my project regardless.

Thanks again for your great help!

[bollwyvl]

The upstream does have those tags.

Feedstocks repos don't get tags, though that would be nice. However, the out-of-git PR discussions are usually critical to understanding changes.

We also don't get bot PRs for long-running branches, so there could be 4.x releases that are missing from here.

i'm having another look at pywin32-on-windows, which is still our big hold-up (for windows vs cpython), but yeah, closing this is fine.

[kevin-bates]

Thanks for the update and the tag pointer (I had seen those earlier - like yesterday - but that's how soon I forget!). Yet, I still don't see those via git log and now realize they reside on the 4.x branch that must have been created prior to 4.11.2 - doh! :blush: (The fog can get pretty thick some days!)