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

provide object storage with lifetimes for config/items/scopes #3740

Open
RonnyPfannschmidt opened this issue Jul 31, 2018 · 1 comment
Open
Labels
type: backward compatibility might present some backward compatibility issues which should be carefully noted in the changelog type: feature-branch new feature or API change, should be merged into features branch type: proposal proposal for a new feature, often to gather opinions or design the API around the new feature

Comments

@RonnyPfannschmidt
Copy link
Member

in various internal and external plugins we find outselfes attaching objects to either items or config as pseudo-private elements sometimes even going as far as creating plugin instances only as means for storage

i'd like to open an api to provide storage to plugins that eases getting a own namespace and controlling for how long something will be stored

@RonnyPfannschmidt RonnyPfannschmidt added type: proposal proposal for a new feature, often to gather opinions or design the API around the new feature type: backward compatibility might present some backward compatibility issues which should be carefully noted in the changelog type: feature-branch new feature or API change, should be merged into features branch labels Jul 31, 2018
@pytestbot
Copy link
Contributor

GitMate.io thinks possibly related issues are #162 (Store terminal width on config object), #1373 (provide a rich collection object in the pytest_modifyitems hook), #1137 (xdist: boxed send an item object to a subprocess), #1649 (unittest instance objects exist for the lifetime of the py.test run), and #1743 (config.fromdictargs applies the dictionary after the config object construction instead of ).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
type: backward compatibility might present some backward compatibility issues which should be carefully noted in the changelog type: feature-branch new feature or API change, should be merged into features branch 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

2 participants