Skip to content
New issue

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

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

Already on GitHub? Sign in to your account

Allow access to custom values in skip markers #7712

Closed
bluetech opened this issue Sep 4, 2020 · 2 comments
Closed

Allow access to custom values in skip markers #7712

bluetech opened this issue Sep 4, 2020 · 2 comments
Labels
topic: marks related to marks, either the general marks or builtin type: proposal proposal for a new feature, often to gather opinions or design the API around the new feature

Comments

@bluetech
Copy link
Member

bluetech commented Sep 4, 2020

This issue discusses the feature request presented in PR #7695.

Currently conditions in skip and xfail markers can have two forms:

  • A boolean (=> a regular Python expression evaluated normally during collection). Can only access global Python values.
  • A string of a Python expression. Evaluated during setup/call time. Has access to os, sys, platform, config.

The feature request is to be able to skip based on custom user values. Proposed solutions so far are:

  1. Use the boolean with global variables. This is not so nice because can't the lifecycle can't be controlled, and importing the necessary values add boilerplate.

  2. (PR Allow contibuting additional global variables for skipif/xfail #7695 by @s0undt3ch) Add a new hook pytest_markeval_namespace which can add new values to the os, sys... list above. Works only for string conditions.

  3. Add a new condition type, a callable, which is evaluated lazily. Allow this callable to take fixtures, as if requested by the item.

We agreed to try approach 3 (or another proposal) for pytest 6.2, but if we don't get to it, merge approach 2.

@Zac-HD Zac-HD added topic: marks related to marks, either the general marks or builtin type: proposal proposal for a new feature, often to gather opinions or design the API around the new feature labels Sep 5, 2020
@manueljacob
Copy link
Contributor

#8124 was merged, can this be closed?

@RonnyPfannschmidt
Copy link
Member

yup, thanks for the note

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
topic: marks related to marks, either the general marks or builtin type: proposal proposal for a new feature, often to gather opinions or design the API around the new feature
Projects
None yet
Development

No branches or pull requests

4 participants