PR: Add package jupyterlab-language-pack-ar-SA

[goanpeca]

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.
• 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 wanted to let you know that I linted all conda-recipes in your PR (recipes/jupyterlab-language-pack-ar-SA) and found some lint.

Here's what I've got...

For recipes/jupyterlab-language-pack-ar-SA:

• 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/jupyterlab-language-pack-ar-SA) and found it was in an excellent condition.

[goanpeca]

@blink1073, @fcollonval, @krassowski do you agree to be added as maintainers?

Thanks!

[blink1073]

👍🏼

[krassowski]

+1 to all language packs

[fcollonval]

I agree

[dbast]

As upstream is onboard here: Wouldn't it be easier to tag a release in the upstream repo and the package that (instead of the individual files from pypi) via a one single multi-output/jinja2-equiped recipe/feedstock into individual conda packages? All those language packs seem to be pretty much similar regarding dependencies and other meta-data and updating once recipe over time should be easier compared to keep multiple of those in sync. Just thinking... or is there anything preventing that?

[goanpeca]

Will try that @dbast

Thanks for the suggestion!

[fcollonval]

At @dbast, thanks for the suggestion. I have one question regarding the multi-packages approach. Is the bot able to update the recipe if only one source on Pypi gets updated?
The scenario here is that one language package may need to be updated due to new translated strings being added independently.

[dbast]

@fcollonval One source definition + multiple outputs recipes are bot-auto-updatable ... that can e.g. be seen here https://github.com/conda-forge/airflow-feedstock/blob/master/recipe/meta.yaml ... and the previous merged PRs: https://github.com/conda-forge/airflow-feedstock/pulls?q=is%3Apr+is%3Aclosed

[goanpeca]

Thanks for the info @dbast just checking, so a single release tag (on github) on the single source would trigger the bot?

[dbast]

yes. that is my understanding.

Additional to that airflow multi output recipe a jinja2 loop could be potentially used to generate all outputs dynamically based on the 27 languages.