add litestar 2.8.0

[bollwyvl]

Checklist

• Title of this PR is meaningful: e.g. "Adding my_nifty_package", not "updated meta.yaml".
• License file is packaged (see here for an example).
• Source is from official source.
• Package does not vendor other packages. (If a package uses the source of another package, they should be separate packages or the licenses of all packages need to be packaged).
• If static libraries are linked in, the license of the static library is packaged.
• Package does not ship static libraries. If static libraries are needed, follow CFEP-18.
• Build number is 0.
• A tarball (url) rather than a repo (e.g. git_url) is used in your recipe (see here for more details).
• GitHub users listed in the maintainer section have posted a comment confirming they are willing to be listed there.
• When in trouble, please check our knowledge base documentation before pinging a team.

References:

• fixes Update to litestar 2.0 starlite-feedstock#47
• unblocks strawberry-graphql v0.219.0 strawberry-graphql-feedstock#162

Notes:

• win-64 builds will fail on -with-cli and -standard due to lack of upstream uvloop support for that platform
  • we could code around it with noarch_platforms or something, but doesn't really seem worth it

[conda-forge-webservices]

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/litestar) and found it was in an excellent condition.

[bollwyvl]

@conda-forge/starlite please comment here if you'd like to co-maintain.

[thewchan]

@bollwyvl sure happy to help

[bollwyvl]

@thewchan thanks, will update when i resolve piccolo -> targ -> ???

[bollwyvl]

yeah, piccolo is a mess, not dealing with it now

[bollwyvl]

Also the pydantic-extra-types stack is missing a bunch of stuff:

-   - nothing provides requested pycountry >=23,<24
-   - nothing provides requested python-ulid >=1,<2
-   - nothing provides pycountry >=23,<24 needed by pydantic-extra-types-with-all-2.5.0-py_0

[bollwyvl]

@conda-forge/staged-recipes @conda-forge/help-python ready for review

[github-actions]

To help direct your pull request to the best reviewers, please mention a topic-specifc team if your recipe matches any of the following: conda-forge/help-c-cpp, conda-forge/help-cdts, conda-forge/help-go, conda-forge/help-java, conda-forge/help-julia, conda-forge/help-nodejs, conda-forge/help-perl, conda-forge/help-python, conda-forge/help-python-c, conda-forge/help-r, conda-forge/help-ruby,or conda-forge/help-rust. Thanks!

[ocefpaf]

@bollwyvl I understand that you want to bring your own tooling for maintaining the recipe and I know you will probably have good arguments to do so. However, we cannot handle that and the long lasting effects are unpredictable. Even though you use a different name for the template recipe, that can be confusing for existing (and future) parsing tools in conda-forge.

Do you mind adapting that recipe to the custom format we support and remove the extra stuff?

[bollwyvl]

the custom format we support

Happy to name the stuff whatever, put it wherever: is there some docs or prior art for examples?

[ocefpaf]

Happy to name the stuff whatever, put it wherever: is there some docs or prior art for examples?

We don't have prior art in what you are trying to achieve. The core group did find two more recipes that ended up passing to the feedstock with those scripts and extra yaml file. See https://github.com/search?q=org%3Aconda-forge%20path%3A*.j2.yaml&type=code

What we ask is that you use just the meta.yaml and remove the extra stuff. We are afraid that extra files that are not supported by conda-forge will cause confusing and can even break future iterations of our infrastructure.

I know that this is frustrating but we are few and it is hard to accommodate custom stuff, specially if all maintainers start building their own!

With all that said, if you believe what you are doing there could benefit the larger community, please get in touch with the bot team and work with them to see if we can assimilate those ideas.

[bollwyvl]

What if I just call it test_recipe.py, which happens to contain a jinja template and happens to also have a meaning when invoked directly with python test_recipe.py --update?

[ocefpaf]

What if I just call it test_recipe.py, which happens to contain a jinja template and happens to also have a meaning when invoked directly with python test_recipe.py --update?

We would need some agreement with the @conda-forge/core group. I'm inclined to reduce the complexity if possible.

[carterbox]

The Windows build will fail, and that's probably OK.

[bollwyvl]

@conda-forge/staged-recipes ready for re-review

[github-actions]

To help direct your pull request to the best reviewers, please mention a topic-specifc team if your recipe matches any of the following: conda-forge/help-c-cpp, conda-forge/help-cdts, conda-forge/help-go, conda-forge/help-java, conda-forge/help-julia, conda-forge/help-nodejs, conda-forge/help-perl, conda-forge/help-python, conda-forge/help-python-c, conda-forge/help-r, conda-forge/help-ruby,or conda-forge/help-rust. Thanks!

[thewchan]

Some other package now depends on this conda-forge/evidently-feedstock#33

[ocefpaf]

@conda-forge/core what do you think about this way for adding the recipe generator?

[bollwyvl]

Updated. Still anticipating fails on win-64, and can take the recipe generator out entirely, just using it in my local repo, if this is really a big sticking point.

[thewchan]

Any update on this? @bollwyvl @conda-forge/core

[svengiegerich]

(Nothing useful to add here, sorry, but I wanted to raise that projects I'm maintaining significantly wait for a bump of the blocked evidently recipe. Would it be possible to skip the failing Windows builds in the short run? Or is there anything else that would help going forward?)

[carterbox]

Past me approved this PR, and since then there have been negligible changes to the recipe. A recipe automation script was removed. #25131 (comment) , so I will merge.

[bollwyvl]

Thanks all.