Add tmuxp and libtmux (noarch python)

[AntoinePrv]

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-webservices]

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/libtmux, recipes/tmuxp) and found some lint.

Here's what I've got...

For recipes/libtmux:

• There are 1 too many lines. There should be one empty line at the end of the file.
• 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.

For recipes/tmuxp:

• There are 2 too many lines. There should be one empty line at the end of the file.
• 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-webservices]

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/libtmux, recipes/tmuxp) and found some lint.

Here's what I've got...

For recipes/libtmux:

• 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.

For recipes/tmuxp:

• 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-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/libtmux, recipes/tmuxp) and found it was in an excellent condition.

[tony]

via tmux-python/tmuxp#924 (comment):

I'm the upstream maintainer of libtmux and tmuxp, I'm okay to try out joining this as a maintainer of this package on conda forge (I'm not sure of the effort involved yet)

[conda-forge-webservices]

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/libtmux, recipes/tmuxp) and found some lint.

Here's what I've got...

For recipes/libtmux:

• noarch packages can't have skips with selectors. If the selectors are necessary, please remove noarch: python.

For recipes/tmuxp:

• noarch packages can't have skips with selectors. If the selectors are necessary, please remove noarch: python.

[conda-forge-webservices]

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/libtmux, recipes/tmuxp) and found some lint.

Here's what I've got...

For recipes/libtmux:

• noarch packages can't have selectors. If the selectors are necessary, please remove noarch: python.

For recipes/tmuxp:

• Selectors are suggested to take a <two spaces>#<one space>[<expression>] form. See lines [14]

[AntoinePrv]

Welcome @tony, thanks for joining. Once this is merged, it will get moved to its own repository.
A lot of things are automated, and all we'll likely be doing is merge PR and ensure dependencies are in sync with the project. Full do is available on conda-forge.org..

Edit: it can take a bit of time to review here due to high reviewer workload, but once merged the process is much quicker.

[conda-forge-webservices]

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/libtmux, recipes/tmuxp) and found some lint.

Here's what I've got...

For recipes/libtmux:

• Non noarch packages should have python requirement without any version constraints.
• Non noarch packages should have python requirement without any version constraints.

For recipes/tmuxp:

• Non noarch packages should have python requirement without any version constraints.
• Non noarch packages should have python requirement without any version constraints.

[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/libtmux, recipes/tmuxp) and found it was in an excellent condition.

[AntoinePrv]

@conda-forge/help-python I think this is ready. I had to make the package an arch one because of a dependency that does not exists on Windows, and because I believe conda-build mistook a Python file for a binary one (and so was making an error).
I think we can merge this and make it noarch in the feedstock once there is no Windows CI.

[ocefpaf]

My guess is that these packages can be OS-noarch. See https://conda-forge.org/docs/maintainer/knowledge_base/#noarch-packages-with-os-specific-dependencies

[AntoinePrv]

Thank you for the feedback! The conda-smithy linter complains about selectors without changes to conda-forge.yaml, is it OK to change that file in the PR on staged-recipe?

[ocefpaf]

is it OK to change that file in the PR on staged-recipe?

You have to add one in the recipe directory, that one will be ported to the feedstock.

[conda-forge-webservices]

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/libtmux, recipes/tmuxp) and found some lint.

Here's what I've got...

For recipes/libtmux:

• noarch packages can't have selectors. If the selectors are necessary, please remove noarch: python.

For recipes/tmuxp:

• noarch packages can't have selectors. If the selectors are necessary, please remove noarch: python.

[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/libtmux, recipes/tmuxp) and found it was in an excellent condition.

[AntoinePrv]

@ocefpaf the error on Windows (something to do with this?) was really convoluted (especially for a noarch package) so the tmuxp package on Windows in simply empty. I think it's a good compromise since anyways the package is of no use without tmux. Let me know what you think.

[ocefpaf]

@ocefpaf the error on Windows (something to do with this?) was really convoluted (especially for a noarch package) so the tmuxp package on Windows in simply empty. I think it's a good compromise since anyways the package is of no use without tmux. Let me know what you think.

I though you did not want Windows there, no? That is why I suggested a OS-noarch, so you could do linux and macOS noarch. Does that make sense?

[ocefpaf]

Suggested change

- __win # [win]

[ocefpaf]

Suggested change

	- {{ PYTHON }} -m pip install --no-deps --no-build-isolation . -vv # [not win]
	- {{ PYTHON }} -m pip install --no-deps --no-build-isolation . -vv

[ocefpaf]

Suggested change

- __win # [win]

[AntoinePrv]

@ocefpaf thank you again for the feedback. I feel like this went full circle, how do you want to move forward?
This is what I see so far, unless you have other suggestions.

A - Regular noarch: python

No selectors. The Windows CI will be failing here but we merge anyways since there will not be Windows CI in the feedstock.
Optionally, we can add __unix dependency. This is is only change the error on Windows from "tmuxp requires libtmux which requires tmux which is not available on Windows" to "tmuxp is not available on Windows" (in idea).

B - noarch: python + win_64 in noarch_platforms with a dummy windows package

Same as before, but we use a Windows noarch_platforms to add selectors and make the CI pass here. This is only to please the Windows CI here. On the downsides it creates a tmuxp package on Windows that is empty (the linter won't accept skip: True # [win] with a __unix constraint).

C- Arch packages with skip: True #[win]

Also works with the CI here, but it needlessly creates many packages. We can reverse it in the feedstock (since again there won't be any Windows CI). On the plus side, it never creates a Windows package.