Skip to content
New issue

Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? # to your account

Adding a TAK server and its support packages #29275

Open
wants to merge 10 commits into
base: main
Choose a base branch
from

Conversation

phreed
Copy link

@phreed phreed commented Feb 25, 2025

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.

freetakserver 2.2.1 has requirement bcrypt==3.1.7, but you have bcrypt 4.2.1.
 │ │ freetakserver 2.2.1 has requirement cryptography==36.0.2, but you have cryptography 44.0.1.
 │ │ freetakserver 2.2.1 has requirement dnspython==2.2.1, but you have dnspython 2.7.0.
 │ │ freetakserver 2.2.1 has requirement greenlet==2.0.2, but you have greenlet 3.1.1.
 │ │ freetakserver 2.2.1 has requirement pillow==9.3.0, but you have pillow 11.0.0.
 │ │ freetakserver 2.2.1 has requirement protobuf==3.18.3, but you have protobuf 5.28.3.
 │ │ freetakserver 2.2.1 has requirement psutil==5.9.4, but you have psutil 6.1.1.
 │ │ freetakserver 2.2.1 has requirement pyOpenSSL==22.0.0, but you have pyopenssl 25.0.0.
 │ │ freetakserver 2.2.1 has requirement python-engineio==4.9.0, but you have python-engineio 4.11.2.
 │ │ freetakserver 2.2.1 has requirement PyYAML==6.0.1, but you have pyyaml 6.0.2.
 │ │ freetakserver 2.2.1 has requirement ruamel.yaml==0.17.21, but you have ruamel-yaml 0.18.10.
 │ │ freetakserver 2.2.1 has requirement ruamel.yaml.clib==0.2.7, but you have ruamel-yaml-clib 0.2.8.
 │ │ freetakserver 2.2.1 has requirement SQLAlchemy==2.0.29, but you have sqlalchemy 2.0.38.
Copy link
Contributor

github-actions bot commented Feb 25, 2025

Hi! This is the staged-recipes linter and I found some lint.

It looks like some changes were made outside the recipes/ directory. To ensure everything runs smoothly, please make sure that recipes are only added to the recipes/ directory and no other files are changed.

If these changes are intentional (and you aren't submitting a recipe), please add a maintenance label to the PR.

File-specific lints and/or hints:

  • pixi.toml:
    • lints:
      • Do not edit files outside of the recipes/ directory.

@conda-forge-admin
Copy link
Contributor

conda-forge-admin commented Feb 25, 2025

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/testresources/recipe.yaml, recipes/digitalpy/recipe.yaml, recipes/asyncio/recipe.yaml, recipes/freetakserver/recipe.yaml) and found it was in an excellent condition.

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

For recipes/testresources/recipe.yaml:

  • ℹ️ noarch: python recipes should usually follow the syntax in our documentation for specifying the Python version.
    • For the host section of recipe, you should usually use python ${{ python_min }} for the python entry.
    • For the test.requires section of recipe, you should usually use 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/digitalpy/recipe.yaml:

  • ℹ️ noarch: python recipes should usually follow the syntax in our documentation for specifying the Python version.
    • For the host section of recipe, you should usually use python ${{ python_min }} for the python entry.
    • For the test.requires section of recipe, you should usually use 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/asyncio/recipe.yaml:

  • ℹ️ noarch: python recipes should usually follow the syntax in our documentation for specifying the Python version.
    • For the host section of recipe, you should usually use python ${{ python_min }} for the python entry.
    • For the test.requires section of recipe, you should usually use 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/freetakserver/recipe.yaml:

  • ℹ️ noarch: python recipes should usually follow the syntax in our documentation for specifying the Python version.
    • For the host section of recipe, you should usually use python ${{ python_min }} for the python entry.
    • For the test.requires section of recipe, you should usually use 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/13529475900. Examine the logs at this URL for more detail.

@phreed
Copy link
Author

phreed commented Feb 25, 2025

I have questions regarding the dependency packages.
Should I split them out into separate feedstocks?
DigitalPy is from the same group as FreeTAKServer but testresources and asyncio are from different sources.

I read https://conda-forge.org/docs/maintainer/adding_pkgs/#packaging-the-license-manually
but I am unclear, should I use the conda-forge license produced by grayskull or use the same license as used by the source? And if from the source should I copy it or just provide a link into the source?

@phreed
Copy link
Author

phreed commented Feb 25, 2025

The example-v1/README.md has some defects:

# V1 recipe format

This recipe is an example of the v1 recipe format.
* [CEP 13](https://github.com/conda/ceps/blob/main/cep-0013.md)
* [CEP 14](https://github.com/conda/ceps/blob/main/cep-0014.md)

The v1 recipe format is fully functional when built with rattler-build,
but is not yet fully supported by conda-forge's automation.

See https://github.com/conda-forge/conda-forge.github.io/issues/2308 for progress on general support for this new format.

@phreed
Copy link
Author

phreed commented Feb 25, 2025

@conda-forge/help-python

@phreed
Copy link
Author

phreed commented Feb 25, 2025

I would like to modify the pixi.toml file to work with the v1 format.

[feature.grayskull.dependencies]
grayskull = ">=2.7.3"
conda-recipe-manager = ">=0.4.1"
[feature.grayskull.tasks.pypi]
description = "generate a recipe for a PyPI package name with `grayskull`"
cmd = "cd recipes && grayskull pypi --strict-conda-forge --use-v1-format"

Maybe add it in as a new task.

Copy link
Contributor

Hi! This is the staged-recipes linter and your PR looks excellent! 🚀

@phreed
Copy link
Author

phreed commented Feb 25, 2025

I see that the win_64 build is failing. How can I get more information on the issue?

# for free to join this conversation on GitHub. Already have an account? # to comment
Development

Successfully merging this pull request may close these issues.

2 participants