Added initial set of packages belonging to the new eozilla ecosystem. #31256

forman · 2025-10-21T15:47:47Z

Checklist

conda-forge-admin · 2025-10-21T15:49:45Z

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 (recipes/procodile/procodile/recipe.yaml, recipes/eozilla/recipe.yaml, recipes/cuiman/cuiman/recipe.yaml, recipes/appligator/appligator/recipe.yaml, recipes/gavicore/gavicore/recipe.yaml, recipes/wraptile/wraptile/recipe.yaml) and found some lint.

Here's what I've got...

For recipes/procodile/procodile/recipe.yaml:

❌ The homepage item is expected in the about section.
❌ noarch: python recipes are required to have a lower bound on the python version. Typically this means putting python >={{ python_min }} in the run section of your recipe. You may also want to check the upstream source for the package's Python compatibility.

For recipes/procodile/procodile/recipe.yaml:

ℹ️ noarch: python recipes should usually follow the syntax in our documentation for specifying the Python version.
- For the host section of the recipe, you should usually use the pin python ${{ python_min }}.* for the python entry.
- For the run section of the recipe, you should usually use the pin python >=${{ python_min }} for the python entry.
- For the tests[].python.python_version or tests[].requirements.run section of the recipe, you should usually use the pin python_version: ${{ python_min }}.* or python ${{ python_min }}.* for the python_version or python entry.
- If the package requires a newer Python version than the currently supported minimum version on conda-forge, you can override the python_min variable by adding a Jinja2 set statement at the top of your recipe (or using an equivalent context variable for v1 recipes).

For recipes/eozilla/recipe.yaml:

❌ The homepage item is expected in the about section.
❌ noarch: python recipes are required to have a lower bound on the python version. Typically this means putting python >={{ python_min }} in the run section of your recipe. You may also want to check the upstream source for the package's Python compatibility.

For recipes/eozilla/recipe.yaml:

ℹ️ noarch: python recipes should usually follow the syntax in our documentation for specifying the Python version.
- For the host section of the recipe, you should usually use the pin python ${{ python_min }}.* for the python entry.
- For the run section of the recipe, you should usually use the pin python >=${{ python_min }} for the python entry.
- For the tests[].python.python_version or tests[].requirements.run section of the recipe, you should usually use the pin python_version: ${{ python_min }}.* or python ${{ python_min }}.* for the python_version or python entry.
- If the package requires a newer Python version than the currently supported minimum version on conda-forge, you can override the python_min variable by adding a Jinja2 set statement at the top of your recipe (or using an equivalent context variable for v1 recipes).

For recipes/cuiman/cuiman/recipe.yaml:

❌ The homepage item is expected in the about section.
❌ noarch: python recipes are required to have a lower bound on the python version. Typically this means putting python >={{ python_min }} in the run section of your recipe. You may also want to check the upstream source for the package's Python compatibility.

For recipes/cuiman/cuiman/recipe.yaml:

ℹ️ noarch: python recipes should usually follow the syntax in our documentation for specifying the Python version.
- For the host section of the recipe, you should usually use the pin python ${{ python_min }}.* for the python entry.
- For the run section of the recipe, you should usually use the pin python >=${{ python_min }} for the python entry.
- For the tests[].python.python_version or tests[].requirements.run section of the recipe, you should usually use the pin python_version: ${{ python_min }}.* or python ${{ python_min }}.* for the python_version or python entry.
- If the package requires a newer Python version than the currently supported minimum version on conda-forge, you can override the python_min variable by adding a Jinja2 set statement at the top of your recipe (or using an equivalent context variable for v1 recipes).

For recipes/appligator/appligator/recipe.yaml:

❌ The homepage item is expected in the about section.
❌ The license item is expected in the about section.
❌ license_file entry is missing, but is required.
❌ noarch: python recipes are required to have a lower bound on the python version. Typically this means putting python >={{ python_min }} in the run section of your recipe. You may also want to check the upstream source for the package's Python compatibility.

For recipes/appligator/appligator/recipe.yaml:

ℹ️ noarch: python recipes should usually follow the syntax in our documentation for specifying the Python version.
- For the host section of the recipe, you should usually use the pin python ${{ python_min }}.* for the python entry.
- For the run section of the recipe, you should usually use the pin python >=${{ python_min }} for the python entry.
- For the tests[].python.python_version or tests[].requirements.run section of the recipe, you should usually use the pin python_version: ${{ python_min }}.* or python ${{ python_min }}.* for the python_version or python entry.
- If the package requires a newer Python version than the currently supported minimum version on conda-forge, you can override the python_min variable by adding a Jinja2 set statement at the top of your recipe (or using an equivalent context variable for v1 recipes).

For recipes/gavicore/gavicore/recipe.yaml:

❌ The homepage item is expected in the about section.
❌ noarch: python recipes are required to have a lower bound on the python version. Typically this means putting python >={{ python_min }} in the run section of your recipe. You may also want to check the upstream source for the package's Python compatibility.

For recipes/gavicore/gavicore/recipe.yaml:

ℹ️ noarch: python recipes should usually follow the syntax in our documentation for specifying the Python version.
- For the host section of the recipe, you should usually use the pin python ${{ python_min }}.* for the python entry.
- For the run section of the recipe, you should usually use the pin python >=${{ python_min }} for the python entry.
- For the tests[].python.python_version or tests[].requirements.run section of the recipe, you should usually use the pin python_version: ${{ python_min }}.* or python ${{ python_min }}.* for the python_version or python entry.
- If the package requires a newer Python version than the currently supported minimum version on conda-forge, you can override the python_min variable by adding a Jinja2 set statement at the top of your recipe (or using an equivalent context variable for v1 recipes).

For recipes/wraptile/wraptile/recipe.yaml:

❌ The homepage item is expected in the about section.
❌ noarch: python recipes are required to have a lower bound on the python version. Typically this means putting python >={{ python_min }} in the run section of your recipe. You may also want to check the upstream source for the package's Python compatibility.

For recipes/wraptile/wraptile/recipe.yaml:

ℹ️ noarch: python recipes should usually follow the syntax in our documentation for specifying the Python version.
- For the host section of the recipe, you should usually use the pin python ${{ python_min }}.* for the python entry.
- For the run section of the recipe, you should usually use the pin python >=${{ python_min }} for the python entry.
- For the tests[].python.python_version or tests[].requirements.run section of the recipe, you should usually use the pin python_version: ${{ python_min }}.* or python ${{ python_min }}.* for the python_version or python entry.
- If the package requires a newer Python version than the currently supported minimum version on conda-forge, you can override the python_min variable by adding a Jinja2 set statement at the top of your recipe (or using an equivalent context variable for v1 recipes).

_{This message was generated by GitHub Actions workflow run https://github.com/conda-forge/conda-forge-webservices/actions/runs/18690367460. Examine the logs at this URL for more detail.}

pont-us · 2025-10-21T16:08:43Z

I am willing to be a maintainer.

forman · 2025-10-21T16:14:00Z

I am willing to be a maintainer.

conda-forge-admin · 2025-10-21T16:21:52Z

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 (recipes/wraptile/recipe.yaml, recipes/appligator/recipe.yaml, recipes/procodile/recipe.yaml, recipes/cuiman/recipe.yaml, recipes/gavicore/recipe.yaml, recipes/eozilla/recipe.yaml) and found it was in an excellent condition.

I do have some suggestions for making it better though...

For recipes/wraptile/recipe.yaml:

ℹ️ noarch: python recipes should usually follow the syntax in our documentation for specifying the Python version.
- For the tests[].python.python_version or tests[].requirements.run section of the recipe, you should usually use the pin python_version: ${{ python_min }}.* or python ${{ python_min }}.* for the python_version or python entry.
- If the package requires a newer Python version than the currently supported minimum version on conda-forge, you can override the python_min variable by adding a Jinja2 set statement at the top of your recipe (or using an equivalent context variable for v1 recipes).

For recipes/appligator/recipe.yaml:

ℹ️ noarch: python recipes should usually follow the syntax in our documentation for specifying the Python version.
- For the tests[].python.python_version or tests[].requirements.run section of the recipe, you should usually use the pin python_version: ${{ python_min }}.* or python ${{ python_min }}.* for the python_version or python entry.
- If the package requires a newer Python version than the currently supported minimum version on conda-forge, you can override the python_min variable by adding a Jinja2 set statement at the top of your recipe (or using an equivalent context variable for v1 recipes).

For recipes/procodile/recipe.yaml:

ℹ️ noarch: python recipes should usually follow the syntax in our documentation for specifying the Python version.
- For the tests[].python.python_version or tests[].requirements.run section of the recipe, you should usually use the pin python_version: ${{ python_min }}.* or python ${{ python_min }}.* for the python_version or python entry.
- If the package requires a newer Python version than the currently supported minimum version on conda-forge, you can override the python_min variable by adding a Jinja2 set statement at the top of your recipe (or using an equivalent context variable for v1 recipes).

For recipes/cuiman/recipe.yaml:

ℹ️ noarch: python recipes should usually follow the syntax in our documentation for specifying the Python version.
- For the tests[].python.python_version or tests[].requirements.run section of the recipe, you should usually use the pin python_version: ${{ python_min }}.* or python ${{ python_min }}.* for the python_version or python entry.
- If the package requires a newer Python version than the currently supported minimum version on conda-forge, you can override the python_min variable by adding a Jinja2 set statement at the top of your recipe (or using an equivalent context variable for v1 recipes).

For recipes/gavicore/recipe.yaml:

ℹ️ noarch: python recipes should usually follow the syntax in our documentation for specifying the Python version.
- For the tests[].python.python_version or tests[].requirements.run section of the recipe, you should usually use the pin python_version: ${{ python_min }}.* or python ${{ python_min }}.* for the python_version or python entry.
- If the package requires a newer Python version than the currently supported minimum version on conda-forge, you can override the python_min variable by adding a Jinja2 set statement at the top of your recipe (or using an equivalent context variable for v1 recipes).

For recipes/eozilla/recipe.yaml:

ℹ️ noarch: python recipes should usually follow the syntax in our documentation for specifying the Python version.
- For the tests[].python.python_version or tests[].requirements.run section of the recipe, you should usually use the pin python_version: ${{ python_min }}.* or python ${{ python_min }}.* for the python_version or python entry.
- If the package requires a newer Python version than the currently supported minimum version on conda-forge, you can override the python_min variable by adding a Jinja2 set statement at the top of your recipe (or using an equivalent context variable for v1 recipes).

_{This message was generated by GitHub Actions workflow run https://github.com/conda-forge/conda-forge-webservices/actions/runs/19104466294. Examine the logs at this URL for more detail.}

forman · 2025-10-22T09:49:41Z

Hi @conda-forge/help-python,

The recipes have passed all checks and linting. Is there anything else I need to do to proceed?
Thank you for your help!

TejasMorbagal · 2025-10-22T10:04:38Z

I am willing to be a maintainer.

ocefpaf · 2025-10-22T11:15:03Z

The recipes have passed all checks and linting. Is there anything else I need to do to proceed?

Yes. Please address #31256 (comment).

ocefpaf · 2025-10-22T12:07:19Z

recipes/appligator/recipe.yaml

@@ -0,0 +1,42 @@
+context:
+  version: 0.0.1
+  python_min: 3.10


Only set python_min if the minimum required version is higher than the conda-forge default.

Suggested change

python_min: 3.10

@ocefpaf Done. Thanks for the fast feedback!

Please remove that line and all others that are <=3.10.

ocefpaf · 2025-10-22T12:44:05Z

Are all these packages just a namespace grab?

@conda-forge/core They are on PyPI, but I'm not sure how to feel about this. We used to review packages :-/

forman · 2025-10-22T13:52:54Z

Are all these packages just a namespace grab?

@conda-forge/core They are on PyPI, but I'm not sure how to feel about this. We used to review packages :-/

No, they are true packages, but well, yes, currently empty. Please take a look at eo-tools/eozilla where the new packages in this PR live and will be release from in the future.

I want to ensure that the names of the package we selected would still be available. It took us a some effort to (1) the find the names that our team would agree on, and (2) that the names are still free on PyPI and conda. We want to avoid extra effort in renaming stuff after a name has been taken by someone else before we have a first dev release.

ocefpaf · 2025-10-22T14:12:32Z

No, they are true packages, but well, yes, currently empty.

Yeah I would be merging a namespace grab, not a package, also I cannot review a code that is not here. The summary doesn't even say what they will do. I do not feel comfortable doing this b/c I cannot say what they will do once published. Sure, an existing package can change as it evolves, but in this case there isn't one and whatever I approve here is not what it will be once released.

@conda-forge/core, if anyone wants to take over this review, please do.

ocefpaf · 2025-10-22T14:13:08Z

Note that I'm not blocking the merge. I just don't want to be the one doing it.

forman · 2025-10-22T14:36:48Z

Yeah I would be merging a namespace grab, not a package, also I cannot review a code that is not here.

I'll provide the first releases with complete metadata asap.

…t sections

h-vetinari · 2025-11-04T23:04:49Z

Hey, just a quick note that we're discussing this case in the larger context of how to deal with such situations in conda-forge/cfep#64. Overall, I think we'll tend to allow it when there's good reason (I can understand that it's hard to find a name that's free both on PyPI and on conda-forge, and we want to enable people to pull that off); you'll just need a little bit more patience please. Once the CFEP is through, we should be able to get this done.

forman · 2025-11-05T10:37:04Z

... you'll just need a little bit more patience please. Once the CFEP is through, we should be able to get this done.

Hi @h-vetinari, thanks so much for taking care! However, I'm planning to close this PR and instead place 6 individual ones with recipes generated by grayskull from the related functional and already published PyPI packages with same names. This is because I realized (a little late) that I cannot get the 6 packages deployed at once because they depend on each other in a certain order.

h-vetinari · 2025-11-05T11:36:58Z

This is because I realized (a little late) that I cannot get the 6 packages deployed at once because they depend on each other in a certain order.

Recipes within a PR here are allowed to depend on each other (except circularly, of course), and will be built in the correct order. So you don't need to break up the PR, unless that helps your workflow (or the reviewers).

…ackages

conda-forge-admin · 2025-11-05T14:24:41Z

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 (recipes/eozilla/meta.yaml, recipes/gavicore/meta.yaml, recipes/cuiman/meta.yaml, recipes/procodile/meta.yaml, recipes/wraptile/meta.yaml, recipes/appligator/meta.yaml) and found some lint.

Here's what I've got...

For recipes/eozilla/meta.yaml:

ℹ️ No valid build backend found for Python recipe for package eozilla using pip. Python recipes using pip need to explicitly specify a build backend in the host section. If your recipe has built with only pip in the host section in the past, you likely should add setuptools to the host section of your recipe.
ℹ️ noarch: python recipes should usually follow the syntax in our documentation for specifying the Python version.
- For the host section of the recipe, you should usually use the pin python {{ python_min }} for the python entry.
- For the run section of the recipe, you should usually use the pin python >={{ python_min }} for the python entry.
- For the test.requires section of the recipe, you should usually use the pin python {{ python_min }} for the python entry.
- If the package requires a newer Python version than the currently supported minimum version on conda-forge, you can override the python_min variable by adding a Jinja2 set statement at the top of your recipe (or using an equivalent context variable for v1 recipes).

For recipes/gavicore/meta.yaml:

ℹ️ No valid build backend found for Python recipe for package gavicore using pip. Python recipes using pip need to explicitly specify a build backend in the host section. If your recipe has built with only pip in the host section in the past, you likely should add setuptools to the host section of your recipe.
ℹ️ noarch: python recipes should usually follow the syntax in our documentation for specifying the Python version.
- For the host section of the recipe, you should usually use the pin python {{ python_min }} for the python entry.
- For the run section of the recipe, you should usually use the pin python >={{ python_min }} for the python entry.
- For the test.requires section of the recipe, you should usually use the pin python {{ python_min }} for the python entry.
- If the package requires a newer Python version than the currently supported minimum version on conda-forge, you can override the python_min variable by adding a Jinja2 set statement at the top of your recipe (or using an equivalent context variable for v1 recipes).

For recipes/cuiman/meta.yaml:

❌ The home item is expected in the about section.
❌ The about section contained an unexpected subsection name. homepage is not a valid subsection name.

For recipes/cuiman/meta.yaml:

ℹ️ No valid build backend found for Python recipe for package cuiman using pip. Python recipes using pip need to explicitly specify a build backend in the host section. If your recipe has built with only pip in the host section in the past, you likely should add setuptools to the host section of your recipe.
ℹ️ noarch: python recipes should usually follow the syntax in our documentation for specifying the Python version.
- For the host section of the recipe, you should usually use the pin python {{ python_min }} for the python entry.
- For the run section of the recipe, you should usually use the pin python >={{ python_min }} for the python entry.
- For the test.requires section of the recipe, you should usually use the pin python {{ python_min }} for the python entry.
- If the package requires a newer Python version than the currently supported minimum version on conda-forge, you can override the python_min variable by adding a Jinja2 set statement at the top of your recipe (or using an equivalent context variable for v1 recipes).

For recipes/procodile/meta.yaml:

ℹ️ No valid build backend found for Python recipe for package procodile using pip. Python recipes using pip need to explicitly specify a build backend in the host section. If your recipe has built with only pip in the host section in the past, you likely should add setuptools to the host section of your recipe.
ℹ️ noarch: python recipes should usually follow the syntax in our documentation for specifying the Python version.
- For the host section of the recipe, you should usually use the pin python {{ python_min }} for the python entry.
- For the run section of the recipe, you should usually use the pin python >={{ python_min }} for the python entry.
- For the test.requires section of the recipe, you should usually use the pin python {{ python_min }} for the python entry.
- If the package requires a newer Python version than the currently supported minimum version on conda-forge, you can override the python_min variable by adding a Jinja2 set statement at the top of your recipe (or using an equivalent context variable for v1 recipes).

For recipes/wraptile/meta.yaml:

ℹ️ No valid build backend found for Python recipe for package wraptile using pip. Python recipes using pip need to explicitly specify a build backend in the host section. If your recipe has built with only pip in the host section in the past, you likely should add setuptools to the host section of your recipe.
ℹ️ noarch: python recipes should usually follow the syntax in our documentation for specifying the Python version.
- For the host section of the recipe, you should usually use the pin python {{ python_min }} for the python entry.
- For the run section of the recipe, you should usually use the pin python >={{ python_min }} for the python entry.
- For the test.requires section of the recipe, you should usually use the pin python {{ python_min }} for the python entry.
- If the package requires a newer Python version than the currently supported minimum version on conda-forge, you can override the python_min variable by adding a Jinja2 set statement at the top of your recipe (or using an equivalent context variable for v1 recipes).

For recipes/appligator/meta.yaml:

ℹ️ No valid build backend found for Python recipe for package appligator using pip. Python recipes using pip need to explicitly specify a build backend in the host section. If your recipe has built with only pip in the host section in the past, you likely should add setuptools to the host section of your recipe.
ℹ️ noarch: python recipes should usually follow the syntax in our documentation for specifying the Python version.
- For the host section of the recipe, you should usually use the pin python {{ python_min }} for the python entry.
- For the run section of the recipe, you should usually use the pin python >={{ python_min }} for the python entry.
- For the test.requires section of the recipe, you should usually use the pin python {{ python_min }} for the python entry.
- If the package requires a newer Python version than the currently supported minimum version on conda-forge, you can override the python_min variable by adding a Jinja2 set statement at the top of your recipe (or using an equivalent context variable for v1 recipes).

_{This message was generated by GitHub Actions workflow run https://github.com/conda-forge/conda-forge-webservices/actions/runs/19105809339. Examine the logs at this URL for more detail.}

conda-forge-admin · 2025-11-05T14:58:06Z

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 (recipes/gavicore/meta.yaml, recipes/procodile/meta.yaml, recipes/appligator/meta.yaml, recipes/wraptile/meta.yaml, recipes/eozilla/meta.yaml, recipes/cuiman/meta.yaml) and found it was in an excellent condition.

I do have some suggestions for making it better though...

For recipes/gavicore/meta.yaml:

ℹ️ noarch: python recipes should usually follow the syntax in our documentation for specifying the Python version.
- For the run section of the recipe, you should usually use the pin python >={{ python_min }} for the python entry.
- If the package requires a newer Python version than the currently supported minimum version on conda-forge, you can override the python_min variable by adding a Jinja2 set statement at the top of your recipe (or using an equivalent context variable for v1 recipes).
ℹ️ top-level output has some malformed specs:

In section run: python >=$9999
Requirement spec fields should match the syntax name [version [build]]to avoid known issues in conda-build. For example, instead of name =version=build, use name version.* build. There should be no spaces between version operators and versions either: python >= 3.8 should be python >=3.8.

For recipes/procodile/meta.yaml:

ℹ️ noarch: python recipes should usually follow the syntax in our documentation for specifying the Python version.
- For the run section of the recipe, you should usually use the pin python >={{ python_min }} for the python entry.
- If the package requires a newer Python version than the currently supported minimum version on conda-forge, you can override the python_min variable by adding a Jinja2 set statement at the top of your recipe (or using an equivalent context variable for v1 recipes).
ℹ️ top-level output has some malformed specs:

In section run: python >=$9999
Requirement spec fields should match the syntax name [version [build]]to avoid known issues in conda-build. For example, instead of name =version=build, use name version.* build. There should be no spaces between version operators and versions either: python >= 3.8 should be python >=3.8.

For recipes/appligator/meta.yaml:

ℹ️ noarch: python recipes should usually follow the syntax in our documentation for specifying the Python version.
- For the run section of the recipe, you should usually use the pin python >={{ python_min }} for the python entry.
- If the package requires a newer Python version than the currently supported minimum version on conda-forge, you can override the python_min variable by adding a Jinja2 set statement at the top of your recipe (or using an equivalent context variable for v1 recipes).
ℹ️ top-level output has some malformed specs:

In section run: python >=$9999
Requirement spec fields should match the syntax name [version [build]]to avoid known issues in conda-build. For example, instead of name =version=build, use name version.* build. There should be no spaces between version operators and versions either: python >= 3.8 should be python >=3.8.

For recipes/wraptile/meta.yaml:

ℹ️ noarch: python recipes should usually follow the syntax in our documentation for specifying the Python version.
- For the host section of the recipe, you should usually use the pin python {{ python_min }} for the python entry.
- For the run section of the recipe, you should usually use the pin python >={{ python_min }} for the python entry.
- If the package requires a newer Python version than the currently supported minimum version on conda-forge, you can override the python_min variable by adding a Jinja2 set statement at the top of your recipe (or using an equivalent context variable for v1 recipes).
ℹ️ top-level output has some malformed specs:

In section host: python $9999
In section run: python >=$9999
Requirement spec fields should match the syntax name [version [build]]to avoid known issues in conda-build. For example, instead of name =version=build, use name version.* build. There should be no spaces between version operators and versions either: python >= 3.8 should be python >=3.8.

For recipes/eozilla/meta.yaml:

ℹ️ noarch: python recipes should usually follow the syntax in our documentation for specifying the Python version.
- For the run section of the recipe, you should usually use the pin python >={{ python_min }} for the python entry.
- If the package requires a newer Python version than the currently supported minimum version on conda-forge, you can override the python_min variable by adding a Jinja2 set statement at the top of your recipe (or using an equivalent context variable for v1 recipes).
ℹ️ top-level output has some malformed specs:

In section run: python >=$9999
Requirement spec fields should match the syntax name [version [build]]to avoid known issues in conda-build. For example, instead of name =version=build, use name version.* build. There should be no spaces between version operators and versions either: python >= 3.8 should be python >=3.8.

For recipes/cuiman/meta.yaml:

ℹ️ noarch: python recipes should usually follow the syntax in our documentation for specifying the Python version.
- For the run section of the recipe, you should usually use the pin python >={{ python_min }} for the python entry.
- If the package requires a newer Python version than the currently supported minimum version on conda-forge, you can override the python_min variable by adding a Jinja2 set statement at the top of your recipe (or using an equivalent context variable for v1 recipes).
ℹ️ top-level output has some malformed specs:

In section run: python >=$9999
Requirement spec fields should match the syntax name [version [build]]to avoid known issues in conda-build. For example, instead of name =version=build, use name version.* build. There should be no spaces between version operators and versions either: python >= 3.8 should be python >=3.8.

_{This message was generated by GitHub Actions workflow run https://github.com/conda-forge/conda-forge-webservices/actions/runs/19106146546. Examine the logs at this URL for more detail.}

…{{")

conda-forge-admin · 2025-11-05T15:42:57Z

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 (recipes/appligator/meta.yaml, recipes/wraptile/meta.yaml, recipes/procodile/meta.yaml, recipes/eozilla/meta.yaml, recipes/gavicore/meta.yaml, recipes/cuiman/meta.yaml) and found it was in an excellent condition.

forman · 2025-11-05T16:25:10Z

Hi @conda-forge/help-python,

The recipes have passed all checks and linting. Is there anything else I need to do to proceed?
Thank you for your help!

FYI @ocefpaf & @h-vetinari: all packages are now fully functional & tested, just as their counterparts on PyPI.

h-vetinari

This LGTM! Thanks for your patience on this! :)

PS. I love the suite of reptile-tech-puns! I had to squint at cuiman to get caiman though, and I had never heard of a gavial before 😅

Added initial set of packages belonging to the new eozilla ecosystem.

b446907

Fixes

4a5c606

Fixes, 2nd round

1d97382

Fixes, 3rd round

9c06cf5

forman added 3 commits October 21, 2025 18:30

Fixes, 4th round

2f8bef2

Fixes, 5th try (moved recipes one level up)

4ef4fcc

fix, 6th round

325295e

github-actions bot added python review-requested labels Oct 22, 2025

closer follow recommendations

03aff72

ocefpaf reviewed Oct 22, 2025

View reviewed changes

Removed python_min entry

c582b13

h-vetinari mentioned this pull request Nov 2, 2025

Add CFEP for package renames conda-forge/cfep#64

Open

forman added 2 commits November 4, 2025 16:35

Switched to functional v0.0.7, adjusted sha256 keys, and updated abou…

ab7e7b4

…t sections

Added hatch to host requirements

3bc0a51

forman added 3 commits November 5, 2025 15:00

Merge branch 'main' into initial-packages

97e5ed8

Updated recipes with output from grayskull

12ca8b5

Merge remote-tracking branch 'origin/initial-packages' into initial-p…

15c9aa1

…ackages

forman added 2 commits November 5, 2025 15:44

Fixes to make conda-forge-linting service happy

a28b226

Fixes to make conda-forge-linting service happy - part 2

a086b68

Fixes to make conda-forge-linting service happy - part 3 ("${{" --> "…

2fcdb01

…{{")

h-vetinari approved these changes Nov 10, 2025

View reviewed changes

h-vetinari merged commit c15cc9e into conda-forge:main Nov 10, 2025
7 checks passed

Uh oh!

Added initial set of packages belonging to the new eozilla ecosystem. #31256

Added initial set of packages belonging to the new eozilla ecosystem. #31256

Uh oh!

Conversation

forman commented Oct 21, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

conda-forge-admin commented Oct 21, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

pont-us commented Oct 21, 2025

Uh oh!

forman commented Oct 21, 2025

Uh oh!

conda-forge-admin commented Oct 21, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

forman commented Oct 22, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

TejasMorbagal commented Oct 22, 2025

Uh oh!

ocefpaf commented Oct 22, 2025

Uh oh!

ocefpaf Oct 22, 2025

Choose a reason for hiding this comment

Uh oh!

forman Oct 22, 2025

Choose a reason for hiding this comment

Uh oh!

ocefpaf Oct 22, 2025

Choose a reason for hiding this comment

Uh oh!

forman Oct 22, 2025

Choose a reason for hiding this comment

Uh oh!

ocefpaf commented Oct 22, 2025

Uh oh!

forman commented Oct 22, 2025

Uh oh!

ocefpaf commented Oct 22, 2025

Uh oh!

ocefpaf commented Oct 22, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

forman commented Oct 22, 2025

Uh oh!

h-vetinari commented Nov 4, 2025

Uh oh!

forman commented Nov 5, 2025

Uh oh!

h-vetinari commented Nov 5, 2025

Uh oh!

conda-forge-admin commented Nov 5, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

conda-forge-admin commented Nov 5, 2025

Uh oh!

conda-forge-admin commented Nov 5, 2025

Uh oh!

forman commented Nov 5, 2025

Uh oh!

h-vetinari left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

6 participants

forman commented Oct 21, 2025 •

edited

Loading

conda-forge-admin commented Oct 21, 2025 •

edited

Loading

conda-forge-admin commented Oct 21, 2025 •

edited

Loading

forman commented Oct 22, 2025 •

edited

Loading

ocefpaf commented Oct 22, 2025 •

edited

Loading

conda-forge-admin commented Nov 5, 2025 •

edited

Loading