python-pytest: add new package#11744
Conversation
| +python3-pluggy \ | ||
| +python3-packaging \ | ||
| +python3-wcwidth | ||
| VARIANT:=python3 |
There was a problem hiding this comment.
Is "variant" still needed after the python2 removal was done?
There was a problem hiding this comment.
There is still a dependency on VARIANT:=python3 in python3-package.mk.
@commodo How do you feel about keeping/removing the variant mechanism? I can see arguments for either option.
(Apologies for hijacking this comment thread for a Python discussion 😂)
There was a problem hiding this comment.
fine to remove VARIANT [from my side];
but we should make it aware to people that it is required in 19.x and 18.x releases;
no good idea about how to do it: document it? add a comment somewhere visible?
i've seen that sometimes people want some newer Python packages [or packages that are only in master] in releases and they ask for them, or try to backport them directly and get stuck, and open issues on Github;
either we leave the VARIANT mechanism for one last release [20.X] or we remove it now and we keep commenting to them that they should put the VARIANT variable [when backporting];
either is fine from my side;
that's pretty much the only things [at this point in time] about VARIANT that i see that is worth worrying about
There was a problem hiding this comment.
The backporting aspect is a factor suggesting that the VARIANT is left in place for now.
In master there might maybe be a default statement/value in python3-package.mk, so that the variant would be unnecessary for new packages (which will not be backported to 19.07). That would enable a gradual removal of VARIANT from master.
There was a problem hiding this comment.
I'm not too concerned about backporting; we can add a note in the readme. Having a section that documents major changes between releases is probably a good idea anyway.
I'm not sure it's possible/easy to have a default value for VARIANT... I know there is a DEFAULT_VARIANT but I don't believe it affects package compilation (actually I'm not really sure what effect it has, if any).
I'm thinking of refactoring python3-package.mk so that different packages can use different aspects of its functionality (calling setup.py, bytecode compilation, shebang manging, etc.). I'll probably take out the variant mechanism as part of that and also do a treewide update.
Until this refactoring is done (whenever it may be 😂) I think Python package PRs should continue including VARIANT:=python3. Would this be ok?
There was a problem hiding this comment.
Until this refactoring is done (whenever it may be joy) I think Python package PRs should continue including
VARIANT:=python3. Would this be ok?
fine by me
jefferyto
left a comment
jefferyto
left a comment
There was a problem hiding this comment.
Also suggest to add HOST_PYTHON3_PACKAGE_BUILD_DEPENDS:=setuptools-scm based on setup_requires.
| URL:=https://docs.pytest.org/en/latest/ | ||
| DEPENDS:= \ | ||
| +python3-light \ | ||
| +python3-atomicwrites \ |
There was a problem hiding this comment.
atomicwrites became a Windows-only dependency in 5.3.0 (pytest-dev/pytest#6148).
| +python3-attrs \ | ||
| +python3-pluggy \ | ||
| +python3-packaging \ | ||
| +python3-wcwidth |
There was a problem hiding this comment.
Also suggest to add:
Signed-off-by: Jan Pavlinec <jan.pavlinec@nic.cz>
jefferyto
left a comment
jefferyto
left a comment
There was a problem hiding this comment.
LGTM - thanks for all your efforts!
4 participants
Maintainer: me
Compile tested: (put here arch, model, OpenWrt version)
Run tested: (put here arch, model, OpenWrt version, tests done)
Description:
This PR adds pytest package. It's related to #8562, because all packages were separated into special PRs.
It could be merged after #10449 and
#11664