Add uvicorn-tschaume

[jan-janssen]

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.

[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 (recipes/uvicorn-tschaume) and found it was in an excellent condition.

[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 (recipes/uvicorn-tschaume) and found some lint.

Here's what I've got...

For recipes/uvicorn-tschaume:

• 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 (recipes/uvicorn-tschaume) and found it was in an excellent condition.

[jan-janssen]

@dopplershift I changed the recipe to noarch can you take another look?

[dopplershift]

How does this one compare with the official? https://pypi.org/project/uvicorn/

[jan-janssen]

It is basically a build of encode/uvicorn#947 for more details: materialsproject/emmet@9131828#r89153314

[beckermr]

It appears this fork is bypassing upstream which wants the feature but is moving more slowly. This is a pretty bad dev practice even if the intent is to switch eventually. IDK if were should be merging recipes like this. Thoughts?

[jan-janssen]

It appears this fork is bypassing upstream which wants the feature but is moving more slowly. This is a pretty bad dev practice even if the intent is to switch eventually. IDK if were should be merging recipes like this. Thoughts?

That is also fine with me.

[jakirkham]

FWIW in situations like this in the past, I've often built my own package with the needed feature/bug fix and stuck it in my own channel. Then whenever the needed changes are included in the upstream package, I can drop my own build of it. For really simple changes, some vendored or backport code in whatever library uses it could work. Maybe these approaches are worth considering

[beckermr]

Good ideas @jakirkham! Both approaches you mention are better than a new feedstock for a temporary fork.

[jan-janssen]

My issue is that conda-forge/emmet-api-feedstock#17 requires uvicorn-tschaume - I am going to discuss it with the developers up-stream.

[Kludex]

You can always talk to the maintainers about their intentions. 🤷