update receipte for jupyter_core 5.1.1

tarrade commented 1 year ago

Checklist

[x] Used a personal fork of the feedstock to propose changes
[ ] 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.

my first try to update a receipte for conda-forge for jupyter_core 5.1.1, very beginner

conda-forge-linter commented 1 year ago

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.

tarrade commented 1 year ago

@conda-forge-admin, please rerender

bollwyvl commented 1 year ago

Downstreams have been acting up with mambabuild. We'll need to replicate this:

https://github.com/conda-forge/jupyter_server-feedstock/blob/main/conda-forge.yml#L12

(and then re-render)

bollwyvl commented 1 year ago

@conda-forge-admin please rerender

bollwyvl commented 1 year ago

This is a new one for me:

  File "/opt/conda/lib/python3.10/site-packages/conda/models/match_spec.py", line 787, in merge
    raise ValueError("Incompatible component merge:\n  - %r\n  - %r"
ValueError: Incompatible component merge:
  - 'mpi_mpich_*'
  - 'mpi_mpich_tempest*'

https://dev.azure.com/conda-forge/feedstock-builds/_build/results?buildId=633680&view=logs&j=4f922444-fdfe-5dcf-b824-02f86439ef14&t=b2a8456a-fb11-5506-ca32-5ccd32538dc0&l=594

bollwyvl commented 1 year ago

I guess about the only thing to do today would be to:

remove the mambabuild thing
comment out the downstream tests
make an issue to track this

tarrade commented 1 year ago

ok so the issue is for:

python3.11
all OS (win, linux and mac)
downstreams task for ipython

I never work before with conda feedstock so everything is new.

For me look like a dependency issue but I am not able to create a local env using

name: test
channels:
  - conda-forge
dependencies:
  - python=3.11
  - pip=22.3
  - ipython=8.7.0
  - traitlets=5.8.0
  - pip:
      - jupyter_core==5.1.1

I don't know what is inside : TEST START: /home/conda/feedstock_root/build_artifacts/pkg_cache/ipython-8.7.0-pyh41d4057_0.conda

but

Collecting package metadata (repodata.json): ...working... done
Solving environment: ...working... WARNING conda.models.version:get_matcher(544): Using .* with relational operator is superfluous and deprecated and will be removed in a future version of conda. Your spec was 1.*, but conda is ignoring the .* and treating it as 1
WARNING conda.models.version:get_matcher(544): Using .* with relational operator is superfluous and deprecated and will be removed in a future version of conda. Your spec was 2.*, but conda is ignoring the .* and treating it as 2
WARNING conda.models.version:get_matcher(544): Using .* with relational operator is superfluous and deprecated and will be removed in a future version of conda. Your spec was 3.*, but conda is ignoring the .* and treating it as 3
failed

seems to indicate some conflict. This is how people fixed the issue mentioned above.

tarrade commented 1 year ago

what confuse me is that for python 3.10 (which is working), the downstream ipython env install a lot of depedencies like pillow, pandas and numpy. It is not the case when I simply install pip install ipython. I don't know what it means when ipython is "local" but seems to be build with some extra "flag" test_extra which add a lot of extra dependencies https://github.com/ipython/ipython/blob/main/setup.cfg

where can I find how ipython local was created ?
ipython: 8.7.0-pyh41d4057_0 local

tarrade commented 1 year ago

It seems that the local installation of ipython use the flag all which add a lot of other dependency: ipyton[all] One strong constraints is pytest<7 It seems that is not compatible with python 3.11.0 (on MacOS at least) but works fine with python 3.10.8 (as for the azure pipelines)


name: test-2
channels:
  - conda-forge
dependencies:
  - python=3.11.0
  - pip=22.3.1
  - pytest<7

Looking for: ['python=3.11.0', 'pip=22.3.1', "pytest[version='<7']"]

Encountered problems while solving:
  - package pytest-2.9.2-py27_0 requires python 2.7*, but none of the providers can be installed

Now if we install ipython instead of ipython[all] then we don't have this dependency on pytest<7 and everything is working fine:

name: test-2
channels:
  - conda-forge
dependencies:
  - python=3.11.0
  - pip=22.3.1
  #- pytest<7
  - pip:
      - jupyter_core==5.1.1
      - ipython @ git+https://github.com/ipython/ipython@ff770b25d03140e6f9355625601d609d4a5464e8#egg=ipyton

but I have no idea how to tell downstream test for ipython to install ipyton and not ipython[all] and if this is what the author want to do.

bollwyvl commented 1 year ago

Yeah, we have rather a lot of downstream because, well jupyter_core is core to a lot of downstreams, and they may not have been tested with this version. Things are complicated by pypy, especially on windows, which prevents us from going to noarch: python, which would simplify this whole thing.

I'll open up a PR that includes this one, so we can see some more experiments.

bollwyvl commented 1 year ago

where can I find how ipython local was created ?

It downloads it from anaconda.org, but in a sneaky, out-of-band way.

ipython env install a lot of depedencies like pillow, pandas and numpy

yeah, these are used during the downstream test, which installs the full #/test/requires.

python 3.11.0 (on MacOS at least)

yes, but which macos, and critically, which architecture, is a rather important variable.

bollwyvl commented 1 year ago

As this one does pass, and at least tests something, i'd be more inclined to merge this one rather than #61, but I'll just leave an approval and see if someone else wants to weighs in... @conda-forge/jupyter_core ready for review.

tarrade commented 1 year ago

yes, but which macos, and critically, which architecture, is a rather important variable. I agree but since py3.11 test are failing for all architectures I was trying to find some dependency issue as this could be independent of the architecture. I did the test on my Mac (11.7.2) but could have similar issue (working for python3.10.8 but failing with python3.11.0). What surprise me is how ipython can pass the test if pytest<7 is not compatible with python3.11.

tarrade commented 1 year ago

It downloads it from anaconda.org, but in a sneaky, out-of-band way.

ah, so if I use the default conda channel I get the issue that ipython is not available for python3.11

Looking for: ['python=3.11.0', 'pip=22.3.1', 'ipython=8.7.0']

Encountered problems while solving:
  - nothing provides requested python 3.11.0**

works for python 3.10.8. If I use the conda-forge channel then it works for both 3.10.8 and 3.11.0

As a non expert, this look like the best explanation

tarrade commented 1 year ago

I also checked and for https://github.com/conda-forge/ipython-feedstock/ it seems that it is only tested for python 3.10.8

conda-forge / jupyter_core-feedstock

update receipte for jupyter_core 5.1.1 #60