MNT: Add noarch: python

[conda-forge-linter]

Hi! This is the friendly automated conda-forge-webservice.

I've made the recipe noarch: python as instructed in #41.

Here's a checklist to do before merging.

• Bump the build number if needed.

Fixes #41

[conda-forge-linter]

Hi! This is the friendly automated conda-forge-linting service.

I wanted to let you know that I linted all conda-recipes in your PR (recipe) and found some lint.

Here's what I've got...

For recipe:

• noarch: python recipes are required to have a lower bound on the python version. Typically this means putting python >=3.6 in both host and run but you should check upstream for the package's Python compatibility.

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

[weiji14]

Might need to pin to Python>=3.7 for noarch, but upstream omegaconf=2.2 hasn't dropped 3.6 yet 😅 See omry/omegaconf#791. What do people think?

This would potentially fix the @dataclass test failure at https://dev.azure.com/conda-forge/feedstock-builds/_build/results?buildId=613911&view=logs&j=656edd35-690f-5c53-9ba3-09c10d0bea97&t=e5c8ab1d-8ff9-5cae-b332-e15ae582ed2d&l=423

+ pytest --ignore tests/test_pydev_resolver_plugin.py --ignore testsstructured_conftest_structured_config.py --ignore teststest_utils.py
ImportError while loading conftest '/home/conda/feedstock_root/build_artifacts/omegaconf_1668712818640/test_tmp/tests/conftest.py'.
tests/__init__.py:103: in <module>
    @dataclass
../_test_env_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placeh/lib/python3.11/dataclasses.py:1221: in dataclass
    return wrap(cls)
../_test_env_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placeh/lib/python3.11/dataclasses.py:1211: in wrap
    return _process_class(cls, init, repr, eq, order, unsafe_hash,
../_test_env_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placeh/lib/python3.11/dataclasses.py:959: in _process_class
    cls_fields.append(_get_field(cls, name, type, kw_only))
../_test_env_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placeh/lib/python3.11/dataclasses.py:816: in _get_field
    raise ValueError(f'mutable default {type(f.default)} for field '
E   ValueError: mutable default <class 'tests.ConcretePlugin.FoobarParams'> for field params is not allowed: use default_factory
Tests failed for omegaconf-2.2.3-pyhd8ed1ab_0.tar.bz2 - moving package to /home/conda/feedstock_root/build_artifacts/broken
WARNING:conda_build.build:Tests failed for omegaconf-2.2.3-pyhd8ed1ab_0.tar.bz2 - moving package to /home/conda/feedstock_root/build_artifacts/broken
TESTS FAILED: omegaconf-2.2.3-pyhd8ed1ab_0.tar.bz2

[maresb]

LGTM, but I'd rather have someone more experienced with omegaconf hit the merge button on this.

Note: We're currently pinning python<3.11 while waiting for an upstream fix.

[maresb]

A question for the senior CF folks: is it safe to close #40 if this is merged?

From #40:

Please note that if you close this PR we presume that the feedstock has been rebuilt, so if you are going to perform the rebuild yourself don't close this PR until the your rebuild has been merged.

[weiji14]

Not sure if setting an upper pin is needed here. I read the issue at #40 (comment) and see some mention of omegaconf linking to hydra, but I don't see omegaconf depending on hydra (I actually think it is hydra which is depending on omegaconf), so not sure what this is all about...

[weiji14]

Oh wait, don't worry about the hydra stuff, that's not actually relevant. I see that Python 3.11 support was added in omegaconf in omry/omegaconf#1032, but will need an omegaconf v2.2.4 release or higher for that patch to be incorporated, so this upper pin is ok (Just need to remember to unpin it in the next release).

[weiji14]

A question for the senior CF folks: is it safe to close #40 if this is merged?

From #40:

Please note that if you close this PR we presume that the feedstock has been rebuilt, so if you are going to perform the rebuild yourself don't close this PR until the your rebuild has been merged.

Yes, this noarch PR will supersede #40, so #40 can be closed afterwards. But see my comment at #42 (comment) on actually getting Python 3.11 to work after this PR is merged. Nevermind, that comment isn't relevant, so yeah, just merge this PR and close #40 afterwards. Python 3.11 should be supported in omegaconf>=2.2.4 or higher.

[maresb]

My question about #40 was meant in the context of the migration, and how it will be interpreted by the infrastructure. For example, maybe it is essential to close #40 so that the migrator will move to omegaconf's dependencies. On the other hand, maybe we don't want that since all the dependencies will be broken because omegaconf is not yet installable for 3.11. So the question is really complicated and subtle.

[weiji14]

My question about #40 was meant in the context of the migration, and how it will be interpreted by the infrastructure. For example, maybe it is essential to close #40 so that the migrator will move to omegaconf's dependencies. On the other hand, maybe we don't want that since all the dependencies will be broken because omegaconf is not yet installable for 3.11. So the question is really complicated and subtle.

I think what usually happens is that once this noarch migration is merged, the bot will detect that Python 3.11 migration PR at #40 has conflicts and close it accordingly (see e.g. conda-forge/setoptconf-feedstock#12, or if you search https://github.com/search?p=3&q=org%3Aconda-forge+Rebuild+for+python310+noarch&type=Issues and look at the closed PRs). So to be clear, I'm not suggesting we close #40 manually, let the bot close it and it should be safe.

Of course, this doesn't fix the Python 3.11 issue for downstream packages, but that's not a problem that can be fixed now either 🙃

[maresb]

Thanks a lot for the great answer to my question!

I do feel a little bad for pushing the migration along with a known bottleneck. If we merge this, perhaps we should open an issue in this feedstock to explain the situation, making it easier for recipe maintainers to understand why their builds are failing.

[weiji14]

I do feel a little bad for pushing the migration along with a known bottleneck. If we merge this, perhaps we should open an issue in this feedstock to explain the situation, making it easier for recipe maintainers to understand why their builds are failing.

Sure, feel free to open an issue about the 'Python 3.11 not working' limitation. Ideally, most Python packages should use noarch when possible (and there's a big effort going on at conda-forge/conda-forge.github.io#1840) so this becomes a non-issue, but it's a work in progress.

[maresb]

Thanks for the link! I was unaware of that effort, but it seems quite exciting!

[maresb]

Thanks @mdraw for the approval!

I propose that we merge this after one day in case there is no further feedback.

[maresb]

The migration situation with descendents looks better than I had expected. Current immediate children are:

• astromodels
• detectron2
• dvc
• fairseq

None of these have any children. It would be really easy before merging this to raise an issue, perhaps with the following text, in each feedstock.

Incoming python311 migration may block on omegaconf
This feedstock has omegaconf as a dependency, and is also awaiting the python311 migration. Omegaconf has just been converted to noarch, but the latest version v2.2.3 is not yet compatible with Python 3.11. Support will be added in v2.2.4. Therefore, if the migrator opens the "Rebuild for python311" PR before the release of omegaconf v2.2.4, the build will fail.

[weiji14]

Ok to merge this?

[maresb]

Thanks @weiji14 for the reminder! We have allowed plenty of time for an objection to be raised, so I just posted issues on the children feedstocks. Let's merge this!