[pytest-dev] pytest 7.2.0 released

[Ronny Pfannschmidt]

pytest-7.2.0
==

The pytest team is proud to announce the 7.2.0 release!

This release contains new features, improvements, and bug fixes,
the full list of changes is available in the changelog:

https://docs.pytest.org/en/stable/changelog.html

For complete documentation, please visit:

https://docs.pytest.org/en/stable/

As usual, you can upgrade from PyPI via:

pip install -U pytest

Thanks to all of the contributors to this release:

* Aaron Berdy
* Adam Turner
* Albert Villanova del Moral
* Alice Purcell
* Anthony Sottile
* Anton Yakutovich
* Babak Keyvani
* Brandon Chinn
* Bruno Oliveira
* Chanvin Xiao
* Cheuk Ting Ho
* Chris Wheeler
* EmptyRabbit
* Ezio Melotti
* Florian Best
* Florian Bruhin
* Fredrik Berndtsson
* Gabriel Landau
* Gergely Kalmár
* Hugo van Kemenade
* James Gerity
* John Litborn
* Jon Parise
* Kevin C
* Kian Eliasi
* MatthewFlamm
* Miro Hrončok
* Nate Meyvis
* Neil Girdhar
* Nhieuvu1802
* Nipunn Koorapati
* Ofek Lev
* Paul Müller
* Paul Reece
* Pax
* Pete Baughman
* Peyman Salehi
* Philipp A
* Ran Benita
* Robert O'Shea
* Ronny Pfannschmidt
* Rowin
* Ruth Comer
* Samuel Colvin
* Samuel Gaist
* Sandro Tosi
* Shantanu
* Simon K
* Stephen Rosen
* Sviatoslav Sydorenko
* Tatiana Ovary
* Thierry Moisan
* Thomas Grainger
* Tim Hoffmann
* Tobias Diez
* Tony Narlock
* Vivaan Verma
* Wolfremium
* Zac Hatfield-Dodds
* Zach OBrien
* aizpurua23a
* gresm
* holesch
* itxasos23
* johnkangw
* skhomuti
* sommersoft
* wodny
* zx.qiu


Happy testing,
The pytest Development Team

___
pytest-dev mailing list
pytest-dev@python.org
https://mail.python.org/mailman/listinfo/pytest-dev

[pytest-dev] preparing a pytest-dev/core social video meetup and preparing ideas for a online/offline sprint in 2023

[Ronny Pfannschmidt]

Hi everyone,


with the pandemic ensuring lack of safe conferences/sprints since a 
while now,
i think its very helpful to create some type of semi-regular interaction 
to get the team closer and to foster progress.



The last pytest sprint is already an awful long while ago, and with the 
lack of safe to visit conferences in the last few years, we haven't had 
many chances to foster social interaction.


In order to change that i want to create a regular round-table whose 
primary focus is getting to know each other and fostering joy in 
interaction, which in turn should be a good help in fostering progress 
for pytest as a whole.



Additionally i would like to see trough with some preparations for a 
pytest summer sprint in 2023
in order to create opportunities to work in person on some of the pain 
points that we where not able to touch/move in the years since the last 
sprint.



-- Ronny


___
pytest-dev mailing list
pytest-dev@python.org
https://mail.python.org/mailman/listinfo/pytest-dev

[pytest-dev] introducing collection boundaries to support expanding fixtures to non-python and testsuites as python packages

[Ronny Pfannschmidt]

Hi everyone,

i would like to break open a number of limitations we have in the 
collection system.


1. parametrize is tied painfully into Python Items

I want to finish my experiment for function definitions and generalize them

This would mean that instead of multiple python collectors invoking 
parametrize internally to functions,

we would collect function definitions.

This would be represented in the collection tree instead of just being a 
implementation detail of the python generate_tests hook


the generate_tests hook would generalize so that it would apply to any 
"definition" not just a Python Function Definition.


(im torn between keeping item or intoducing a Parameterization Node, 
aining insights on that will have to wait until definition is part of 
the collection tree)



2. pytests unawareness of tests in packages that may/must install vs 
tests in local test folders create painful breakages with doctests/tests 
inside of packages that must install/reinstall for testruns



i'd like to enable a basic awareness of installed tests vs local tests 
vs editable tests (and fail pytest if installed tests differ from the 
local files)


this also includes better awareness of paths/meta paths and pep420


3. testsuites for reuse or purposes like system testing cannot natively 
be shipped as python packages,


collecting them creates painful effects wrt local vs remote filenames as 
well as collection paths vs import paths



it should be possible to have testsuites that ship as pytohn packages 
and to parametrize/configure them.



for that i would like to propose a system building on top of the 
packaging awareness of pytest, and extending it with mechanisms to 
either call defined testsuites and/or referring to external testuites 
and including configured versions of those in current testruns


exact mechanisms for configuration/nesting/"testsuite cycles" and more 
are yet to be determined



but examples i'd like to support are stuff like having tools and 
frameworks provide basic tests for stuff like "base behaviors of well 
behaved plugins of a framework", "sanity tests for features of of 
framework plugins"



i'd love to get inputs/considerations and concerns as i'll focus on 
those topics in order in the next few months.



-- Ronny

___
pytest-dev mailing list
pytest-dev@python.org
https://mail.python.org/mailman/listinfo/pytest-dev

[pytest-dev] assessing hatch/hatching for python package management

[Ronny Pfannschmidt]

Hi everyone,


in https://github.com/pytest-dev/pluggy/pull/362 i prepared to move 
pluggy to hatch.


I hope to eventually move most if not all of pytest-dev over to it.

Hatch is a new and modern tool for python package creation.
it follows the relevant peps, and has a superset of tox features as well.

I already adopted it to a number of my personal and at work projects,
and even dropped eventually creating a own packaging tool for it.

I believe its a bit win for the python ecosystem to get away from
the legacy of setuptools/distutils, and to me hatch is the best of its 
kind as potential replacement.



I'd love to get some more impressions on this before merging.


-- Ronny


___
pytest-dev mailing list
pytest-dev@python.org
https://mail.python.org/mailman/listinfo/pytest-dev

[pytest-dev] On ensuring sustainable maintenance of pytest-dev projects

[Ronny Pfannschmidt]

Hi everyone,

Please read with the caveat that this stems from a gut feeling that's not yet 
quantitative verified.

As pytest-dev is growing, so is the number of projects that suffer bus-factor 
and/or non-maintenance.


I believe a more active approach to ensuring maintenance /maintainer influx is 
needed.

Else projects like pytest-asyncio, pytest-xdist, execnet, apipkg and more are 
just going to face bitrot and pain.

The ratio between people with maintainer bit vs people that can and will do the 
work seems to be at a alarmingly low ratio.

I don't have a good idea for changing that yet, but my impression is that we 
gotta start doing the work to ensure pytest-dev won't turn into a graveyard 
with a few pained grave keepers.

-- Ronny
___
pytest-dev mailing list
pytest-dev@python.org
https://mail.python.org/mailman/listinfo/pytest-dev

[pytest-dev] looking for additional maintainers for pytest-asyncio

[Ronny Pfannschmidt]

Hi everyone,

unfortunatelyTin Tvrtković,
the maintainer of pytest-asyncio is currently
not in a position to do more than the bare minimum for pytest-asyncio.

As such PRs and PR review stalled.

Pytest-core want to help the project, however neither me, nor a good 
part of pytest-core is that familiar with async/asyncio yet.


As such neither pytest-core nor Tin are in a position to mentor someone 
new/unfamiliar into pytest-asyncio.


As such, we'd appreciate if someone that's already familiar could step 
up in order for the project to gain some more traction again


Anyone interested please reach out to the pytest-dev ml and/or me 
personally.


Regards, Ronny
___
pytest-dev mailing list
pytest-dev@python.org
https://mail.python.org/mailman/listinfo/pytest-dev

Re: [pytest-dev] pytest-parallel submission

[Ronny Pfannschmidt]

Based on the fact that pytest-parallel massively monkey-patches the 
internals of pytest ,


Im -1 on adding it to pytest-dev

code like 
https://github.com/browsertron/pytest-parallel/blob/master/pytest_parallel/__init__.py#L222-L231 
gets me pretty nervous about hopefully upcoming major changes.


until it can be done without monkeypatching pytest internals about 
fixture/session state,

i would prefer not to have it directly associated with pytest-dev,

I certainly don't want to be responsible for pytest-parallel when we 
break those internals in future.


-- Ronny

Am 02.09.21 um 09:51 schrieb Éloi Rivard:

[...] I think it would be important to have an active maintainer to do the
move, otherwise we risk it just staying abandoned, but now in a different
place.

There are a few volunteers already.


Having said that, I'm +1.

Great! Thank you.

Éloi

___
pytest-dev mailing list
pytest-dev@python.org
https://mail.python.org/mailman/listinfo/pytest-dev

___
pytest-dev mailing list
pytest-dev@python.org
https://mail.python.org/mailman/listinfo/pytest-dev

Re: [pytest-dev] How can I suppress cleanups when a test fails

[Ronny Pfannschmidt]

in case you use a orm/abstraction layer, sqlite in a tmpdir can be a 
wonderful companion


in case you use another db, you can actually have failures do a db/data 
dump if you like,


unfortunately i'm not aware of a tmp_path alike db setup/teardown tool

--Ronny

Am 15.04.21 um 23:00 schrieb Eliot, Christopher:


Thank you. This might be helpful, but I also have other resources that 
are not files that I would like to selectively clean up or not.  These 
resources are in a relational DB, not a file system.  And no, I can’t 
just wrap everything in a big transaction and then roll it back, 
unfortunately.


Topher Eliot

*From:* Ronny Pfannschmidt 

Hi Christopher,

if you use the tmpdir/tmp_path fixtures pytest provides,
just don't do additional cleanup, pytest keeps the last 3 basetemps 
around precisely for that use-case and drops older ones


-- Ronny

Am 15.04.21 um 21:56 schrieb Eliot, Christopher:

My test suit generates some intermediate files and other resources
which typically would be deleted upon termination of the test. 
However, if there is a failure, I would like to leave them in
place to help in diagnosing the failure.

Is there a clean way to do this?

I’m already using a fixture to do cleanup, so I’m prepared to use
some aspect of the fixture if that’s appropriate.

Thanks,

Topher Eliot

___
pytest-dev mailing list
pytest-dev@python.org
https://mail.python.org/mailman/listinfo/pytest-dev

Re: [pytest-dev] How can I suppress cleanups when a test fails

[Ronny Pfannschmidt]

Hi Christopher,

if you use the tmpdir/tmp_path fixtures pytest provides,
just don't do additional cleanup, pytest keeps the last 3 basetemps 
around precisely for that use-case and drops older ones



-- Ronny

Am 15.04.21 um 21:56 schrieb Eliot, Christopher:


My test suit generates some intermediate files and other resources 
which typically would be deleted upon termination of the test.  
However, if there is a failure, I would like to leave them in place to 
help in diagnosing the failure.


Is there a clean way to do this?

I’m already using a fixture to do cleanup, so I’m prepared to use some 
aspect of the fixture if that’s appropriate.


Thanks,

Topher Eliot


___
pytest-dev mailing list
pytest-dev@python.org
https://mail.python.org/mailman/listinfo/pytest-dev
___
pytest-dev mailing list
pytest-dev@python.org
https://mail.python.org/mailman/listinfo/pytest-dev

Re: [pytest-dev] pytest documentation

[Ronny Pfannschmidt]

I second Ran,

its great to finally see someone someone do this with care.

-- Ronny

Am 14.03.21 um 08:53 schrieb Ran Benita via pytest-dev:

On Sun, Mar 14, 2021, at 01:27, Daniele Procida wrote:

Hello pytest team, now that I have been at this a few days, I wanted to
check in to see how you feel how it's going.

I feel the improvements thus far have been great.
  

Does the burden of doing things this way seem excessive? Is there
anything you would you like me to do differently, or are you happy for
me continue like this?

I'm happy :)


Thanks for merging all the PRs so swiftly.

Thanks for working on this project!

Ran
___
pytest-dev mailing list
pytest-dev@python.org
https://mail.python.org/mailman/listinfo/pytest-dev

___
pytest-dev mailing list
pytest-dev@python.org
https://mail.python.org/mailman/listinfo/pytest-dev

Re: [pytest-dev] Transfer of pyfakefs to pytest-dev?

[Ronny Pfannschmidt]

Hi,

i'm not sure if this should go under pytest-dev,
if i had found the time to make https://github.com/cogs-of-testing be 
actually practical/known yet, i'd sugest it for there.


-- Ronny


Am 05.03.21 um 19:59 schrieb mrbean-bremen via pytest-dev:
After the successful transfer of pytest-order (thank you for that 
smooth experience!), I have been thinking about the transfer of 
another library - pyfakefs - where I am a contributor. I have been 
discussing this with the package maintainer, John McGehee, who is also 
in favor for this, and decided to first ask here if that is feasible.


pyfakefs (https://github.com/jmcgeheeiv/pyfakefs) is a library that 
mocks the file system. It has originally been developed by Mike Bland 
at Google, later transferred to GitHub (after the shutdown of Google 
Code in 2011), where John McGehee has forked it, added direct support 
for unittest and doctest, and has maintained it since then (with my 
help since a few years ago). Later a contributor added support for 
pytest via the fs fixture, with more support for pytest following 
eventually. Today the fs fixture is probably the main means to access 
pyfakefs, judging by the issues and the dependent repositories.


So, while pyfakefs is not a pure pytest plugin, and it doesn't follow 
the naming convention pytest-xx, we thought that it would be a good 
idea to transfer it to pytest-dev, with the following goals:


- ensure continued maintenance

- increase compatibility with pytest and pytest-plugins

- improve visibility of the package, especially for pytest developers

- ideally, benefit from the larger community to get more code reviews 
and issue reports


For reference see also https://github.com/jmcgeheeiv/pyfakefs/issues/590

What do you think? Thanks!




___
pytest-dev mailing list
pytest-dev@python.org
https://mail.python.org/mailman/listinfo/pytest-dev

[pytest-dev] my limited/reduced availability until at least mid-september/october

[Ronny Pfannschmidt]

Hi everyone,

i just wanted to inform everyone, that due to corona and my specific 
family situation,

we are still in a mitigation situation.

This is one of the key factors of my reduced engagement with pytest and 
the community.


By September we will move into into a new flat and get daycare for the 
toddler again.
Once we are settled after that and had some time to relax+reorient i'll 
pick up more pytest joy again.


Regards and stay healthy
Ronny

___
pytest-dev mailing list
pytest-dev@python.org
https://mail.python.org/mailman/listinfo/pytest-dev

Re: [pytest-dev] hardcode 4.x mid-2020 EOL

[Ronny Pfannschmidt]

Hi Bruno, Thomas,

given that thanks to the release automation work Bruno and the others 
did put in,
the effort for doing releases after community contributions is very 
sustainable.


I believe its fair to leave it open for until there was about a full 
year without a new contribution/release.


Should the automation eventually change an the cost for doing the 
releases changes,

it seems fair to drop the offer at that point.

We should however put it into very clear writing that any 
backporting/bugfixing is up to the python2+pytest using community, 
pytest-core will not handle any of that on volunteer time.


-- Ronny


Am 04.07.20 um 15:01 schrieb Bruno Oliveira:

Hi Thomas,

Thanks for bringing this up! Hardcoding the date for 4.6 EOL is 
something we should discuss.


So far we have had a few releases since the beginning of the year: 
January, May and June, with contributions from the community.


Given our overhead is relatively small (review merge a PR and make the 
release), and if a user is going through the trouble of contributing a 
fix it probably means it blocks/bother them enough to care to make a 
PR, I personally don't mind extending our commitment of making new 4.6 
releases contributions until the end of the year, and stating that 
officially.


I would like to hear what others think about this though.

Cheers,



On Wed, Jul 1, 2020 at 7:49 AM Thomas Grainger > wrote:


By most calculations mid-2020 has now passed,

I propose hardcoding mid-2020 to some date in the (very) near future,
eg 2020-08-01

Thomas Grainger
___
pytest-dev mailing list
pytest-dev@python.org 
https://mail.python.org/mailman/listinfo/pytest-dev


___
pytest-dev mailing list
pytest-dev@python.org
https://mail.python.org/mailman/listinfo/pytest-dev
___
pytest-dev mailing list
pytest-dev@python.org
https://mail.python.org/mailman/listinfo/pytest-dev

[pytest-dev] A Short Personal Post Morten for the pytest exodus

[Ronny Pfannschmidt]

Hello everyone,


** This was originally intended to be send out mid April but got 
intentionally delayed to ensure Holger could do the communication for 
the resolution, i finally picked it up again to send it out **



After failing a number of times to sit down and actually throw together 
a reasonable post mortem, I decided to at least try to write up a basic 
summary.



Before continuing please take a look at Adrin Jalali: Open Source - CoC 
- Conflicts 


His writing gives an outside perspective on the issues at hand.


Overall I don't want to attribute malice to Daniel, however we have 
built up a sad story about failed communications and a failed process. 
Early in the process just a bit after the first CoC Report on Daniel, I 
had a phone call with him and exited it under the impression that things 
are better now, the next morning I woke up to a complete “annihilation” 
of all his issues/prs (rage closed?).



At that point in time I reached the frustrating conclusion that I 
couldn't get through to him, and as far as I know we never got a 
satisfying explanation for that. That event also changed my perception 
of him as my trust was gone. In the weeks and months that followed the 
behaviour stayed the same and Bruno and I tried to get the CoC to act, 
as small little details that border on CoC violations and just drain our 
will to work on things kept accumulating.



At the same time I also didn't want to push for intense action, as I 
consider myself a “affected party” and would like to see someone with a 
more clear head on things cut out some clear decisions.



What I perceived then was the helpless situation that

1.

   I couldn’t give Daniel the direly needed feedback in a sensible manner

2.

   The CoC Team also didn't.


So the Situation kept “giving” - to the point where I would sometimes 
fail to communicate to Daniel the way I would like to as the frustration 
kept getting to me.I then quit the CoC team in frustration, but only 
with a relatively short unhappy note.


Some more weeks passed in which Bruno and I worked with each other to 
have a little outlet.



However when Bruno finally called quits, that setup was gone, I 
hesitated a while and then decided to join the exodus.



As far as i can tell in retrospect, there are many points where i see 
potential “what if’s”,


However when things happened I didn't see those.


My own inexperience at CoC enforcement plays a role, given the current 
situation I sure wish I had acted earlier and more. Also I tried to be 
nice even though the situation begged for a more direct and honest 
approach, after all bad behaviour needs early and effective feedback to 
correct and to be clear for all sides.



With my departure from the CoC team I felt that I shed myself of that 
part of the responsibility (as I didnt perceive an effect) , but it 
certainly is my responsibility to protect myself from bad behavior.



While I would prefer that this was done in an effective and positive 
way, I recognize that shortcomings in the communication between Daniel 
and me, The CoC team and me as well as my inexperience with situations 
of that kind, have contributed towards the current outcome.



After I sent out the short message about quitting as well, I underwent a 
number of emotions, but in the end I do feel a great relief, I have shed 
myself of a role that became negative to me.


Now I have quite some more emotions to unpack and reorient myself.


I want to be part of a CoC-Team again - but next time I want to actually 
be trained in the process,I do believe that CoC Teams are an important 
tool to keep communities working,but as Adrin wrote, one has to hone a 
particular set of skills to do it decisively and quickly.


I believe part of why the CoC process with pytest went so frustrating in 
the case at hand is that all 4 of the initial members are trying to be 
nice people, and I'm very sure the other 3 are way nicer than I am. 
However that particular trait hinders a certain positive harshness and 
in a way paves a road to hell with good intentions. It’s my impression 
that we all missed our opportunities to sort this out more favourable 
for everyone involved.



I also want to continue to contribute to the python testing ecosystem in 
one way or another,After all I had myself lined up for  a multi-year 
process of refactorings and minor breaking changes of pytest internals 
to get node structures, fixtures and test execution in general ready for 
the things to come.



What I see myself doing in the near future is something like minimal 
modular composable testing components.



I also can see myself returning to pytest, but that's not yet something 
for which I have a concrete idea.



For now I want to reinvent myself a bit and see where that leads to.


-- Ronny

___
pytest-dev mailing list
pytest-dev@python.org

Re: [pytest-dev] How to duplicate pytest.Item inside function 'pytest_collection_modifyitems'?

[Ronny Pfannschmidt]

*copey with the correct mail*

Hi Shiban,

its not safely possible to clone a item in general.

A) you need to make a new nodeid to prevent some issues

B) there is no safe cloning mechanism declared, different subtypes of 
items have different mutable state you dont want to mix


I believe the closest you can get is creating a new item that is 
reasonably equivalent.

The Details of that would depend on what the actual Item subtype is.

-- Ronny

Am 15.04.20 um 07:45 schrieb Ronny Pfannschmidt:


Hi Shiban,

its not safely possible to clone a item in general.

A) you need to make a new nodeid to prevent some issues

B) there is no safe cloning mechanism declared, different subtypes of 
items have different mutable state you dont want to mix


I believe the closest you can get is creating a new item that is 
reasonably equivalent.

The Details of that would depend on what the actual Item subtype is.

-- Ronny

Am 14.04.20 um 23:46 schrieb Anton Shiban:


Hi,


Can you please guide me *how to* *clone pytest.Item?*

I want to take one *item* from *items* array (inside function 
‘pytest_collection_modifyitems’) and clone that *item* and add it to 
*items* array back.


Can someone please guide to do this?


Thanks,

Shiban.


___
pytest-dev mailing list
pytest-dev@python.org
https://mail.python.org/mailman/listinfo/pytest-dev
___
pytest-dev mailing list
pytest-dev@python.org
https://mail.python.org/mailman/listinfo/pytest-dev

Re: [pytest-dev] also leaving pytest-dev for now

[Ronny Pfannschmidt]

Hi Dinu,

i can understand your anger and sadness.
I left the CoC team over the handling of this.
Now that i removed myself from the Situation
and the Position of Responsibility i am free to resolve the Fallout as i 
want.


I believe i can speak for all 3 of us when i say that we don't want to 
obtain "justice" and "Resolution" by a angry mob.


I for myself will go an enjoy easter with my family and
will sort out the rest once i have my mind and feelings settled.

I appreciate you get angry for us, because it shows you care,
i wish you a positive outlet for that, from own experience
i know that part can be tricky.

-- Ronny

Am 11.04.20 um 10:46 schrieb Dinu Gherman:


This makes me very sad for all three of you who leave), and I don’t understand 
why in the “discussion” so far at least on twitter everybody tries to be 
“politically correct” and not discuss the cause of this issue. To me it seems 
like the CoCs that so many were proud of having do not work as intended. And 
for our community it would be better to handle such “issues” in the same “open” 
way that we are proud of doing when working on “open source”. We have too many 
bastards ruining the world already.

Best,

Dinu



On 10. Apr 2020, at 23:05, Ronny Pfannschmidt  
wrote:

Hi everyone,


after contemplaing a while i decided to join Bruno and Anthony.
When i returned from my hiatus i declared that joy will be important,

currently that joy is absent.


-- Ronny

___
pytest-dev mailing list
pytest-dev@python.org
https://mail.python.org/mailman/listinfo/pytest-dev

___
pytest-dev mailing list
pytest-dev@python.org
https://mail.python.org/mailman/listinfo/pytest-dev

[pytest-dev] also leaving pytest-dev for now

[Ronny Pfannschmidt]

Hi everyone,


after contemplaing a while i decided to join Bruno and Anthony.
When i returned from my hiatus i declared that joy will be important,

currently that joy is absent.


-- Ronny

___
pytest-dev mailing list
pytest-dev@python.org
https://mail.python.org/mailman/listinfo/pytest-dev

Re: [pytest-dev] junitxml incremental output writing

[Ronny Pfannschmidt]

Hi Floris,

this morning i remebered another idea.

instead of creating the junitxml report direcly,
one could use the new reportlog plugin, and add report replay to it, 
thus collecting the report logs on the first run, then combiningthe 
pytest reports to junitxml on the second run.



-- Ronny

Am 06.04.20 um 21:45 schrieb Floris Bruynooghe:

Hey Ronny,

On Mon 06 Apr 2020 at 09:24 +0200, Ronny Pfannschmidt wrote:

an incremental writer has to continuously update either the
pre-overstretched xml header of the report or continuously rewrite the
file at once.

Cool. Thanks for putting this so succinctly!


Another approach could be to just write the xml report parts of each
item into a junitxml.parts file and
at the end of the test to just recombine the file with the enclosing xml
element.

This is possibly an interesting approach.  I think CI can usually
already combine many reports into one so the simplest implementation
could be to write one report per test and not even bother with
recombining.


I think people that care about it should come up with it.

Here I agree entirely.  I'm only curious to explore the general ideas a
bit so I know what to tell people to work on when they ask about this.


No one feel like critiquing the idea of providing an API to plugins that
can be used to trigger reports to be (re)written right now?


Cheers,
Floris

___
pytest-dev mailing list
pytest-dev@python.org
https://mail.python.org/mailman/listinfo/pytest-dev

Re: [pytest-dev] junitxml incremental output writing

[Ronny Pfannschmidt]

**re-sent with correct sender mail**

Hi Floris,

an incremental writer has to continuously update either the 
pre-overstretched xml header of the report or continuously rewrite the 
file at once.


An implementation would be tricky and need someone to dedicate to it to 
weed out the detail ussues that will invariably crop up.


Another approach could be to just write the xml report parts of each 
item into a junitxml.parts file and
at the end of the test to just recombine the file with the enclosing xml 
element.


I think people that care about it should come up with it.

-- Ronny

Am 05.04.20 um 15:12 schrieb Floris Bruynooghe:

Hello all,

One of the most common things users of pytest-timeout struggle with is
that they lose Junit XML reporting when a timeout occurs.  This never
bothered me, it was by design, but that doesn't stop users from being
bothered.

Which made me wonder, does anyone know if there's a reason that the
Junit XML reporting can't write it's report incrementally as each test
executed?  Not sure that would work well with xdist though.

An additional thing or alternative would be if there's a hook that we
could use from plugins to say "finish reporting now".  So
e.g. pytest-timeout could report a failure for the test which timed out,
call this hook and only then terminate the process.


I'm only bouncing around ill-thought through ideas around this to see
what other people think.

Cheers,
Floris
___
pytest-dev mailing list
pytest-dev@python.org
https://mail.python.org/mailman/listinfo/pytest-dev

___
pytest-dev mailing list
pytest-dev@python.org
https://mail.python.org/mailman/listinfo/pytest-dev

[pytest-dev] pytest 5.4.0 released

[Ronny Pfannschmidt]

pytest-5.4.0
===

The pytest team is proud to announce the 5.4.0 release!

pytest is a mature Python testing tool with more than a 2000 tests
against itself, passing on many different interpreters and platforms.

This release contains a number of bug fixes and improvements, so users are 
encouraged
to take a look at the CHANGELOG:

https://docs.pytest.org/en/latest/changelog.html

For complete documentation, please visit:

https://docs.pytest.org/en/latest/

As usual, you can upgrade from PyPI via:

pip install -U pytest

Thanks to all who contributed to this release, among them:

* Anthony Sottile
* Bruno Oliveira
* Christoph Buelter
* Christoph Bülter
* Daniel Arndt
* Daniel Hahler
* Holger Kohr
* Hugo
* Hugo van Kemenade
* Jakub Mitoraj
* Kyle Altendorf
* Minuddin Ahmed Rana
* Nathaniel Compton
* ParetoLife
* Pauli Virtanen
* Philipp Loose
* Ran Benita
* Ronny Pfannschmidt
* Stefan Scherfke
* Stefano Mazzucco
* TWood67
* Tobias Schmidt
* Tomáš Gavenčiak
* Vinay Calastry
* Vladyslav Rachek
* Zac Hatfield-Dodds
* captainCapitalism
* cmachalo
* gftea
* kpinc
* rebecca-palmer
* sdementen


Happy testing,
The pytest Development Team

___
pytest-dev mailing list
pytest-dev@python.org
https://mail.python.org/mailman/listinfo/pytest-dev

[pytest-dev] Proposal: Elevating Ran Benita/@bluetech from Contributor to Core

[Ronny Pfannschmidt]

Hi everyone,

over the last few months Ran demonstrated both excellent communication 
and contribution.

I believe Ran would make a great addition to the Core team.

So after reaching out to Ran to check if that's ok,
I'm asking the rest us to formalize addition..

-- Ronny

___
pytest-dev mailing list
pytest-dev@python.org
https://mail.python.org/mailman/listinfo/pytest-dev

[pytest-dev] [RFC] experimenting with using matrix as chat/community platform for potentially superseding irc

[Ronny Pfannschmidt]

Hi Everyone,

since a while now i have stopped using irc directly/controlled and
instead switched to a setup using matrix that i like much better.

Matrix enables a few features that i really like, for example

* multiple synced clients (on my computers and my mobile)
* server side persistent history (where i don't have to manage/juggle logs)

In addition my personal perception of the communication structure on 
matrix is close to irc in a sense.
(this is a emotional perception hard to put into word, but i like that 
matrix is IRC-like with nice features while being not like slack at all).


In order to see how acceptance works out for that,
i'd like to set up a community with  a small number of channels for dev 
talk, support, general chatter.


However before starting, i would like to get feedback from the community 
on the ML.



-- Ron

___
pytest-dev mailing list
pytest-dev@python.org
https://mail.python.org/mailman/listinfo/pytest-dev

Re: [pytest-dev] [proposal] global and per item data stashes

[Ronny Pfannschmidt]

Hi Victor,

i took a initial look and i believe the tooling can intersect

a "stash/storage" would be used for the live part,
and its tear-down could transfer the harvest details to a more
compact/permanent storage/location/bubble them up.

at work we are currently working on a service that stores/tracks test
results/logs/selenium screen-shots for test execution,
i marked it down as a research target for integration with pytest-harvest

- Ronny

On Wed, 16 Oct 2019 at 16:27, Victor Maryama 
wrote:

> Hi guys! I am no expert, but maybe is this something that could replace or
> intersect with the functionality provided by
> https://smarie.github.io/python-pytest-harvest/ (fixture_store and
> results_bag fixtures)? And maybe the code that is saving fixture and test
> context information like in allure-pytest.
>
> Although probably it would require the stashes not to be torn down, in
> opposition to the original Ronny's idea.
>
> Le mer. 16 oct. 2019 à 15:42, Ronny Pfannschmidt  a
> écrit :
>
>> a little side note as  i was  just having a little discussion about this
>> with a native speaker,
>> the word stash isn`t quite fitting the concept - the name scoped_storage
>> came to mind,
>> we might need to iterate on the concept name a bit to get to something
>> that makes deeper sense
>>
>> - Ronny
>>
>> On Wed, 16 Oct 2019 at 09:45, Ronny Pfannschmidt 
>> wrote:
>>
>>>
>>>
>>> On Wed, 16 Oct 2019 at 01:23, Bruno Oliveira 
>>> wrote:
>>>
>>>> Hi Ronny,
>>>>
>>>> As you have shared this before in chat, at first glance it sounds like
>>>> a good idea!
>>>>
>>>> Some questions that we can probably elaborate on once we have something
>>>> more concrete to discuss:
>>>>
>>>> 1. You say "each stash  would be a context manager", but it is not
>>>> clear to me how this would work in practice, as most uses today that need
>>>> to decorate the object need to do it across multiple function calls (for
>>>> example, creating an object in `pytest_configure` and storing it in a
>>>> stash, only to retrieve the data later in another hook). Can you provide
>>>> examples to clarify this?
>>>>
>>> the value returned from get_stash would be the value the entering of the
>>> context manager yielded
>>> this also means that for a item or a class there may be multiple stashes
>>> over a test-run, as each stash would have been entered in a different
>>> lifecycles
>>>
>>>
>>>
>>>>
>>>> 2. If we are to use the "stash" for fixtures, we need  a way to specify
>>>> stashes whose other lifetimes than function and session, like class, module
>>>> and package. Any idea how this would look like?
>>>>
>>> those stashes would just be modelled on the belonging nodes, so fixtures
>>> for session, stashed on session, fixtures for class, stashed on class and
>>> so on
>>>
>>>
>>>
>>>>
>>>> Other than that, where do you want to go from here? Keep the discussion
>>>> here in the mailing list, move it to the issue tracker, or somewhere else?
>>>>
>>> i'd like some more iteration on the basics, then perhaps a quick video
>>> conference to solidify the thinking,
>>> then set up a github project.
>>>
>>> -- Ronny
>>>
>>>
>>>
>>>>
>>>> Cheers,
>>>> Bruno.
>>>>
>>>>
>>>> On Tue, Oct 15, 2019 at 10:03 AM Ronny Pfannschmidt <
>>>> rpfan...@redhat.com> wrote:
>>>>
>>>>> Problem: for the storage of helper objects that either tackle certain
>>>>> global tracking details or that track information over the testprotocol
>>>>> lifecycle of test items, we use monkeypatchs and generally just munge
>>>>> around in either the pytest config object or item objects.
>>>>>
>>>>> I would like to propose a new API putting those details into
>>>>> consideration.
>>>>>
>>>>>
>>>>>
>>>>>   config.get_stash(owner, type=pytest.NamespaceStash) # valid over the
>>>>> pytest session lifetime
>>>>>   item.get_stash(owner, type=pytest.NamespaceStash) # valid across the
>>>>> run-test protocol cycle of item
>>>>>
>>>>> Each stash  would be a context manager and construction would get
>>

Re: [pytest-dev] [proposal] global and per item data stashes

[Ronny Pfannschmidt]

a little side note as  i was  just having a little discussion about this
with a native speaker,
the word stash isn`t quite fitting the concept - the name scoped_storage
came to mind,
we might need to iterate on the concept name a bit to get to something that
makes deeper sense

- Ronny

On Wed, 16 Oct 2019 at 09:45, Ronny Pfannschmidt 
wrote:

>
>
> On Wed, 16 Oct 2019 at 01:23, Bruno Oliveira  wrote:
>
>> Hi Ronny,
>>
>> As you have shared this before in chat, at first glance it sounds like a
>> good idea!
>>
>> Some questions that we can probably elaborate on once we have something
>> more concrete to discuss:
>>
>> 1. You say "each stash  would be a context manager", but it is not clear
>> to me how this would work in practice, as most uses today that need to
>> decorate the object need to do it across multiple function calls (for
>> example, creating an object in `pytest_configure` and storing it in a
>> stash, only to retrieve the data later in another hook). Can you provide
>> examples to clarify this?
>>
> the value returned from get_stash would be the value the entering of the
> context manager yielded
> this also means that for a item or a class there may be multiple stashes
> over a test-run, as each stash would have been entered in a different
> lifecycles
>
>
>
>>
>> 2. If we are to use the "stash" for fixtures, we need  a way to specify
>> stashes whose other lifetimes than function and session, like class, module
>> and package. Any idea how this would look like?
>>
> those stashes would just be modelled on the belonging nodes, so fixtures
> for session, stashed on session, fixtures for class, stashed on class and
> so on
>
>
>
>>
>> Other than that, where do you want to go from here? Keep the discussion
>> here in the mailing list, move it to the issue tracker, or somewhere else?
>>
> i'd like some more iteration on the basics, then perhaps a quick video
> conference to solidify the thinking,
> then set up a github project.
>
> -- Ronny
>
>
>
>>
>> Cheers,
>> Bruno.
>>
>>
>> On Tue, Oct 15, 2019 at 10:03 AM Ronny Pfannschmidt 
>> wrote:
>>
>>> Problem: for the storage of helper objects that either tackle certain
>>> global tracking details or that track information over the testprotocol
>>> lifecycle of test items, we use monkeypatchs and generally just munge
>>> around in either the pytest config object or item objects.
>>>
>>> I would like to propose a new API putting those details into
>>> consideration.
>>>
>>>
>>>
>>>   config.get_stash(owner, type=pytest.NamespaceStash) # valid over the
>>> pytest session lifetime
>>>   item.get_stash(owner, type=pytest.NamespaceStash) # valid across the
>>> run-test protocol cycle of item
>>>
>>> Each stash  would be a context manager and construction would get access
>>> to both item and config.
>>>
>>> This would for example enable to express the junit xml logger object and
>>> configuration as
>>>
>>> `config.get_stash(__name__, JunitXMlTracker)`
>>>
>>> Just as  it would allow other plugin to store node lifecycle related
>>> details within the node using a well known mechanism
>>>
>>> Incidentally this would also be a good fit for the fixture system and
>>> setup-state in general to store information.
>>>
>>> The basic assumption being that only the stashes of the items that are
>>> currently active are valid, and other stashes are torn down,
>>> then fixtures as well as the fixture request would nicely fit that
>>> storage mechanism, and would also generalize across the node tree from
>>> session down to individual items.
>>>
>>> (considering the layout, it might be sensible to even replace
>>> config.get_stash with something
>>> like session.get_stash)
>>>
>>> The idea is still rather fuzzy in my head and i would love to di either
>>> text based brainstorming on it, or a actual video call.
>>>
>>> -- Ronny
>>>
>>> Red Hat GmbH, http://www.de.redhat.com/, Registered seat: Grasbrunn,
>>> Commercial register: Amtsgericht Muenchen, HRB 153243,
>>> Managing Directors: Charles Cachera, Michael Cunningham, Michael O'Neill, 
>>> Eric Shander
>>>
>>> ___
>>> pytest-dev mailing list
>>> pytest-dev@python.org
>>> https://mail.python.org/mailman/listinfo/pytest-dev
>>>
>>
>
> --
>
> Red Hat GmbH, http://www.de.redhat.com/, Registered seat: Grasbrunn,
> Commercial register: Amtsgericht Muenchen, HRB 153243,
> Managing Directors: Charles Cachera, Michael Cunningham, Michael O'Neill, 
> Eric Shander
>
>

-- 

Red Hat GmbH, http://www.de.redhat.com/, Registered seat: Grasbrunn,
Commercial register: Amtsgericht Muenchen, HRB 153243,
Managing Directors: Charles Cachera, Michael Cunningham, Michael
O'Neill, Eric Shander
___
pytest-dev mailing list
pytest-dev@python.org
https://mail.python.org/mailman/listinfo/pytest-dev

Re: [pytest-dev] [proposal] global and per item data stashes

[Ronny Pfannschmidt]

On Wed, 16 Oct 2019 at 01:23, Bruno Oliveira  wrote:

> Hi Ronny,
>
> As you have shared this before in chat, at first glance it sounds like a
> good idea!
>
> Some questions that we can probably elaborate on once we have something
> more concrete to discuss:
>
> 1. You say "each stash  would be a context manager", but it is not clear
> to me how this would work in practice, as most uses today that need to
> decorate the object need to do it across multiple function calls (for
> example, creating an object in `pytest_configure` and storing it in a
> stash, only to retrieve the data later in another hook). Can you provide
> examples to clarify this?
>
the value returned from get_stash would be the value the entering of the
context manager yielded
this also means that for a item or a class there may be multiple stashes
over a test-run, as each stash would have been entered in a different
lifecycles



>
> 2. If we are to use the "stash" for fixtures, we need  a way to specify
> stashes whose other lifetimes than function and session, like class, module
> and package. Any idea how this would look like?
>
those stashes would just be modelled on the belonging nodes, so fixtures
for session, stashed on session, fixtures for class, stashed on class and
so on



>
> Other than that, where do you want to go from here? Keep the discussion
> here in the mailing list, move it to the issue tracker, or somewhere else?
>
i'd like some more iteration on the basics, then perhaps a quick video
conference to solidify the thinking,
then set up a github project.

-- Ronny



>
> Cheers,
> Bruno.
>
>
> On Tue, Oct 15, 2019 at 10:03 AM Ronny Pfannschmidt 
> wrote:
>
>> Problem: for the storage of helper objects that either tackle certain
>> global tracking details or that track information over the testprotocol
>> lifecycle of test items, we use monkeypatchs and generally just munge
>> around in either the pytest config object or item objects.
>>
>> I would like to propose a new API putting those details into
>> consideration.
>>
>>
>>
>>   config.get_stash(owner, type=pytest.NamespaceStash) # valid over the
>> pytest session lifetime
>>   item.get_stash(owner, type=pytest.NamespaceStash) # valid across the
>> run-test protocol cycle of item
>>
>> Each stash  would be a context manager and construction would get access
>> to both item and config.
>>
>> This would for example enable to express the junit xml logger object and
>> configuration as
>>
>> `config.get_stash(__name__, JunitXMlTracker)`
>>
>> Just as  it would allow other plugin to store node lifecycle related
>> details within the node using a well known mechanism
>>
>> Incidentally this would also be a good fit for the fixture system and
>> setup-state in general to store information.
>>
>> The basic assumption being that only the stashes of the items that are
>> currently active are valid, and other stashes are torn down,
>> then fixtures as well as the fixture request would nicely fit that
>> storage mechanism, and would also generalize across the node tree from
>> session down to individual items.
>>
>> (considering the layout, it might be sensible to even replace
>> config.get_stash with something
>> like session.get_stash)
>>
>> The idea is still rather fuzzy in my head and i would love to di either
>> text based brainstorming on it, or a actual video call.
>>
>> -- Ronny
>>
>> Red Hat GmbH, http://www.de.redhat.com/, Registered seat: Grasbrunn,
>> Commercial register: Amtsgericht Muenchen, HRB 153243,
>> Managing Directors: Charles Cachera, Michael Cunningham, Michael O'Neill, 
>> Eric Shander
>>
>> ___
>> pytest-dev mailing list
>> pytest-dev@python.org
>> https://mail.python.org/mailman/listinfo/pytest-dev
>>
>

-- 

Red Hat GmbH, http://www.de.redhat.com/, Registered seat: Grasbrunn,
Commercial register: Amtsgericht Muenchen, HRB 153243,
Managing Directors: Charles Cachera, Michael Cunningham, Michael
O'Neill, Eric Shander
___
pytest-dev mailing list
pytest-dev@python.org
https://mail.python.org/mailman/listinfo/pytest-dev

[pytest-dev] [proposal] global and per item data stashes

[Ronny Pfannschmidt]

Problem: for the storage of helper objects that either tackle certain
global tracking details or that track information over the testprotocol
lifecycle of test items, we use monkeypatchs and generally just munge
around in either the pytest config object or item objects.

I would like to propose a new API putting those details into consideration.



  config.get_stash(owner, type=pytest.NamespaceStash) # valid over the
pytest session lifetime
  item.get_stash(owner, type=pytest.NamespaceStash) # valid across the
run-test protocol cycle of item

Each stash  would be a context manager and construction would get access to
both item and config.

This would for example enable to express the junit xml logger object and
configuration as

`config.get_stash(__name__, JunitXMlTracker)`

Just as  it would allow other plugin to store node lifecycle related
details within the node using a well known mechanism

Incidentally this would also be a good fit for the fixture system and
setup-state in general to store information.

The basic assumption being that only the stashes of the items that are
currently active are valid, and other stashes are torn down,
then fixtures as well as the fixture request would nicely fit that storage
mechanism, and would also generalize across the node tree from session down
to individual items.

(considering the layout, it might be sensible to even replace
config.get_stash with something
like session.get_stash)

The idea is still rather fuzzy in my head and i would love to di either
text based brainstorming on it, or a actual video call.

-- Ronny

Red Hat GmbH, http://www.de.redhat.com/, Registered seat: Grasbrunn,
Commercial register: Amtsgericht Muenchen, HRB 153243,
Managing Directors: Charles Cachera, Michael Cunningham, Michael
O'Neill, Eric Shander
___
pytest-dev mailing list
pytest-dev@python.org
https://mail.python.org/mailman/listinfo/pytest-dev

Re: [pytest-dev] Maintenance of pytest-forked

[Ronny Pfannschmidt]

Fabulous, thanks

For some tasks it's a joy if they are already done when you get to them

--Ronny 

Am 2. Oktober 2019 19:58:23 MESZ schrieb Floris Bruynooghe :
>I've created a pytest-forked-developers team, invited untitaker and
>gave
>the team write permissions on pytest-forked.  I'll ask for forgiveness
>and undo if that was undesired ;)
>
>Cheers,
>Floris
>
>
>On Wed 02 Oct 2019 at 17:41 +0200, Ronny Pfannschmidt wrote:
>
>> +1
>>
>> On Wed, 2 Oct 2019 at 16:26, Markus Unterwaditzer
>
>> wrote:
>>
>>> Hi,
>>>
>>> I use pytest-forked and would like to add a few more features to it
>>> revolving around gradually opting in or out of forking before
>testing.
>>> Since it it unmaintained I volunteer to help out with that. What are
>your
>>> thoughts?
>>>
>>> Thanks,
>>> Markus (untitaker on github)
>>> ___
>>> pytest-dev mailing list
>>> pytest-dev@python.org
>>> https://mail.python.org/mailman/listinfo/pytest-dev
>>>
>___
>pytest-dev mailing list
>pytest-dev@python.org
>https://mail.python.org/mailman/listinfo/pytest-dev
___
pytest-dev mailing list
pytest-dev@python.org
https://mail.python.org/mailman/listinfo/pytest-dev

Re: [pytest-dev] Maintenance of pytest-forked

[Ronny Pfannschmidt]

+1

On Wed, 2 Oct 2019 at 16:26, Markus Unterwaditzer 
wrote:

> Hi,
>
> I use pytest-forked and would like to add a few more features to it
> revolving around gradually opting in or out of forking before testing.
> Since it it unmaintained I volunteer to help out with that. What are your
> thoughts?
>
> Thanks,
> Markus (untitaker on github)
> ___
> pytest-dev mailing list
> pytest-dev@python.org
> https://mail.python.org/mailman/listinfo/pytest-dev
>


-- 

Red Hat GmbH, http://www.de.redhat.com/, Registered seat: Grasbrunn,
Commercial register: Amtsgericht Muenchen, HRB 153243,
Managing Directors: Charles Cachera, Michael Cunningham, Michael
O'Neill, Eric Shander
___
pytest-dev mailing list
pytest-dev@python.org
https://mail.python.org/mailman/listinfo/pytest-dev

Re: [pytest-dev] [core] Tidelift Funding

[Ronny Pfannschmidt]

Am 06.05.19 um 16:03 schrieb Bruno Oliveira:

Hi Ronny,

On Sun, May 5, 2019 at 11:09 AM Ronny Pfannschmidt 
<mailto:opensou...@ronnypfannschmidt.de>> wrote:


i think its a good idea to have this as a opt-in.

Currently a Fair Share Mechanism on a opt in basis seems fair,
if we ever hit a situation where someone could have a reasonably
set up part/full-time position primarily on pytest we should take
a look at how division is fair in that case.


Agreed, thanks Ronny.

If nobody objects, I plan to move this forward later this week.

One question is how do we track which maintainers are opting to 
receive funding.




I'm thinking of opening an issue which lists the contributors 
receiving the funding; maintainers are then free to post a comment 
indicating if they want to start/stop receiving funding, at which 
point we update the original post. Another option would be to use the 
Wiki, but we don't receive change notifications so there's a chance of 
we getting out of sync with the configuration on Tidelift. Suggestions?



we should make a git repo where we track meta level documentation,
that way we chould have a ci with credentials run the checks

i wonder if tidelift hasn an api published for that


Another question is regarding admins of the Tidelift dashboard. I 
volunteer to do it, but would like more people to also be admins to 
reduce the bus factor, so other volunteers are appreciated as well.


in about 2-3 Months i can Commit to such role as well.


Cheers Ronny




Cheers,
Bruno.

-- Ronny


Am 03.05.19 um 14:11 schrieb Bruno Oliveira:

Hi Floris,

On Thu, May 2, 2019 at 2:25 PM Floris Bruynooghe mailto:f...@devork.be>> wrote:

Why the rules about active?  Seems complicated and more open to
arguing.  I liked the Pillow guidelines you linked:
https://github.com/orgs/pytest-dev/teams/contributors can express
interest and https://github.com/orgs/pytest-dev/teams/core
decides on
split (which I guess can be anything from 0% to 100%).  With
the same
assumption that the core members are reasonable that should
end up as
roughly the same.

Mind you in practice I have no issue with the above proposal
of people
right now, but would also not mind if e.g. hpk or ronny
wanted to be
part right now (I'll pass myself).  Likewise there are
probably cases
where I wouldn't mind people not in core being paid for some
time.


I wrote those "rules" just to come up with a solid proposal in
the e-mail, but I do like yours better. Letting developers opt-in
to a share is fair and reasonable, certainly.

I think we should even always split the funding evenly between
those opting to receive it, to further avoid any arguing on that.

But in general I'm +1, let's make it happen if there's anyone
interested
in getting paid.


Great, let's see what others think.

Cheers,
Bruno.

___
pytest-dev mailing list
pytest-dev@python.org  <mailto:pytest-dev@python.org>
https://mail.python.org/mailman/listinfo/pytest-dev


___
pytest-dev mailing list
pytest-dev@python.org
https://mail.python.org/mailman/listinfo/pytest-dev

Re: [pytest-dev] pytest slack reporting plugin proposal

[Ronny Pfannschmidt]

Hi Arseniy,

thanks for your proposal,
this is definitively useful for pytest users, which use slack.
However pytest itself does not.

If pytest-dev takes this on, there is a need of slack aware/using
maintainers that move this along (else its just going to painfully and
slowly degrade)
I encourage Interested/Invested  parties to reach out so we can understand
the bus-effects we need to consider.
I believe this is a nice and useful addition, but we need to ensure that
long term maintenance under the pytest-dev umbrella is a reality.

-- Ronny

Am Mi., 24. Apr. 2019 um 12:00 Uhr schrieb Arseniy Antonov <
arseny.anto...@gmail.com>:

> Hello,
> I've developed a plugin for sending pytest results to the slack.
> I suppose it may be a useful tool for the pytest community, so I want to
> contribute it to the pytest-dev.
> Please review:
>
> https://github.com/ArseniyAntonov/pytest-slack
>
> --
> --
> Regards.
> Arseny Antonov
> ___
> pytest-dev mailing list
> pytest-dev@python.org
> https://mail.python.org/mailman/listinfo/pytest-dev
>


-- 

Red Hat GmbH, http://www.de.redhat.com/, Registered seat: Grasbrunn,
Commercial register: Amtsgericht Muenchen, HRB 153243,
Managing Directors: Charles Cachera, Michael Cunningham, Michael
O'Neill, Eric Shander
___
pytest-dev mailing list
pytest-dev@python.org
https://mail.python.org/mailman/listinfo/pytest-dev

[pytest-dev] enhancing the assertion rewriting experience with custom integration/workflows

[Ronny Pfannschmidt]

Hi everyone,

at a project at work which integrates pytest
we did build a custom workflow around invoking tests and pytest.

This in turn triggers a lot of warnings from the assertion rewriter about
things that have been already imported.

at first glance fixing this seems rather problematic, as the configuration
of the assertion rewriting is deeply bound to the pytest configuration and
it seems we cant do something simple and crude like letting a pth file fix
the issue.

i believe opening up the hooking system could be best done by moving it to
a package with some sort of singleton control anyway - then pytest would be
just a consumer of that api enabling if not enabled and push in its own
"import roots".

i'd like ot hear other impressions and ideas on this as well.

-- Ronny
___
pytest-dev mailing list
pytest-dev@python.org
https://mail.python.org/mailman/listinfo/pytest-dev

[pytest-dev] another "i have had it moment" and a stern request ro review our interaction with backward compatibility

[Ronny Pfannschmidt]

Hi everyone,

a few days i was trying to replicate an issue in the python shell, and
quickly realized, that outside of actually doing a complete pytest.main
invocation there is simply no practical and sane way to get a config
object that is not in a utterly broken unusable state to begin with.

Again and again i keep running into things that have deep and nastyly
hidden dependencies that are seemingly impossible to resolve.

And we get clear resutls from that - again and again certain features
simply cant be implemented or fearlessly delivered as the shoddy house
of cards falls appart with spooky actions at a distance.

Be it marks that smear over class hierachies or fixture definitions
that blow up for undiscoverable reasons when trying to introduce the
multi scope fixture system.

Again and again many of us run into massive impediments when trying to
develop features simply for strange actions at distance.

This is an accumulative cost in many ways - in particular for a project
driven primarily by volunteers - every hour we sacrafice to this altar
of technical debt is an hour lost for improving the project and/or
working on actual features.

>From my perspective this issue directly grows out of driving a large
part of pytests development by examples and tests, but precluding
stepping back and doing actual design.

The history of marks makes a perfect example of such an horror storry.
Each iteration adding a new minimal element while adding a huge factor
to the structural error as it grew.

I really want to hammer down there that "minimal" is very different
from "minimal viable" - leaving design uncontested for too long is an
ramp up for unsustainable technical debt.

Its aslo critical to note that for **me** there is a inherent
dishonesty in trying to stay backward compatible and not putting
forward a design and development process that deeply supports it -
right now we can observe a state of fragility from pytest where it
feels like every feature release triggers some regression - while at
the same time we keep and keep shipping features that are structurally
and fundamentally broken since years (yield tests, config init, ...).

This setup, which gives me the impression it is "designed" to make the
project fail its user (aka its broken to begin with and now it will
break some more), is a massive emotional drain. It painfully twists
around the sense of responsibility simply due to the perceived inherent
base-level of failure - and **I** want to do and feel better.

However with the current flow of releases and with our backward
compatibility policies in place i am under a very general impression
that i cant really do anything about it, and even if i try it would
drag on for years to generate even basic positive results - this
impression is a killer to my motivation - as it **feels** like it would
take years to even get a initial iteration out to the users - and the
process of fixing the issues in general would drag on over not only
years - but decades.

A timeflow like that would commpletely disconnect me from perceptions
of reward or archivement  - in turn making it even less likely to
succeed or even start.

This is a open source project that volunteer driven - fixing deeper
issues should connect to feeling an archivement - but with out current
setup what seems to be in for **me** is more like dread, fear and
depression - a general defeat.

Thats not something i want to allow anymore. 

**I** want to feel good about my work on pytest.
**I** want to feel the archivements i have on pytest.

and because of that

**I** have to make sure the project can support that.

So **I** want to invite all of you,


Lets make pytest a project again where

* we claim suport for backward compatibility and our actions and
results show for it
* we can enjoy the act of adding new features and enhancing the
ecosystem
* we can have better and quicker feedback, not just from the fabulous
people that work on it - but also the users.


**I** strongly beleive that this is doable, but it will require cutting
some bad ends.

We need to enhance layering, it doesnt have to be perfect but we do
have to be able to keep things appart sanely and we need to have
objects in valid states per default (invalid states should only be
possible deliberately, not accidentially)

We need to talk/write about design more - the difference between
minimal and viable after all only shows itself in the heat and fruction
of different perspectives and oppinions clashing.

We need a conversation and interaction with our advanced users, so they
dont end up on old and dead pytest versions (like pypy for example).

We need a pervasive chain reason to bring trough the period of
papercuts where we do shift around layering so the ecosystem can keep
up (saving the structural integrity of pytest at the expense of
destroying the ecosystem would be a dissaster).

of course there is a obligatory white on red "make pytest great again"
cap in planning ;P

-- Ronny

[pytest-dev] breaking releases required - sorting out FunctionDefinition and Compatproperties

[Ronny Pfannschmidt]

Hi everyone,

introducing FunctionDefinition to the collectiontree will trigger
indirect api breaches for the compat property setup we have in place to
support node.CollectorClass

im unwilling to spend a hard to estimate amount of time on a feature
that is indeed deprecated since years and will be removed in near
future,

so i rather want it gone and out of the way now so i can actually work
on structral cleanup of things that will stay rather than resurrecting
the dead.

i propose we prepare an actual breraking release since its about time
for that since quite a while.



-- Ronny

___
pytest-dev mailing list
pytest-dev@python.org
https://mail.python.org/mailman/listinfo/pytest-dev

Re: [pytest-dev] Results of the "drop python 3" poll and what i envision to do about it

[Ronny Pfannschmidt]

Hi Bruno,

Am Montag, den 01.10.2018, 08:13 -0300 schrieb Bruno Oliveira:
> Hi Ronny,
> 
> On Mon, Oct 1, 2018 at 5:01 AM RonnyPfannschmidt <
> opensou...@ronnypfannschmidt.de> wrote:
> > Hi Everyone,
> > 
> > 
> > 
> > the python3 support poll has run its on
> > 
> > https://twitter.com/ossronny/status/1043837215175057408
> > 
> > 
> > 
> > The results have a interesting shape.
> > 
> > 
> > 
> > 37%now
> > 
> > 09%with 3.4 mid 2019
> > 
> > 38%with the python 2.7 eol
> > 
> > 16%a year after py 2.7 eol
> > 
> > 
> > 
> > 468 votes in the final result.
> > 
> > 
> > 
> > 
> > 
> > Its my belief that a increase of the of the sample size wouldn't
> > have
> > 
> > changed the outcome of the poll.
> > 
> > I observed it rather quickly normalizing into that shape.
> > 
> > I consider the 2 peaks important indications of the desires and
> > 
> > considerations of people.
> > 
> > 
> > 
> > By my own wishes i'd just go ahead and drop python2 as well, but i
> > don't
> > 
> > consider 37% of the community sample to be enough to warrant
> > something
> > 
> > with such drastic effects right now.
> > 
> > When summing up with the ~9% of the "with 3.4" and also weighting
> > in the
> > 
> > larger time-frame and my impression about the rounding twitter uses
> > we
> > 
> > get a subjective number of ~49%+-1%.
> > 
> > Which i consider a good context for dropping the "general support
> > for
> > 
> > python3".
> > 
> > 
> > 
> > So together with support for python3.4 i want pytest to drop
> > support for
> > 
> > python2 for the general development.
> > 
> > 
> > 
> > As for maintenance branches for python2 - i proposed the setup in
> > an
> > 
> > earlier mail and i would like to make a basic outline for its
> > support.
> > 
> > the pytest core developers should actively support, maintain and
> > 
> > backport to this branch until python2.7 goes eol,
> > 
> > at that point we should transition the python2 maintenance
> > involvement
> > 
> > from the core developers from active to passive.
> 
> Sounds good, we should prepare a section in the docs with that
> outline, and put it in our sidebar. 
> 
> What is not clear to me though is when we will start the python2-
> maintenance branch. As I understand it, the maintenance branch would
> go live once we make the first python 3 only release, correct? When
> do you think we should plan for that to happen? End of 2020 or
> sooner?

In the plan i outlined, the first python 3 only release would be the
one that drops 3.4 mid-2019 - at that point in time the maintenance
branch would be prepared before release merge time.-- Ronny
>   
> > Meaning that instead of actively working on porting changes and
> > pushing
> > 
> > releases,
> > 
> > we instead support the wider community with needs to bring in
> > changes
> > 
> > they require and support them with review and releasing.
> > 
> > I believe half a year is more than enough to stabilize and sort out
> > the
> > 
> > 2.7 maintenance branch,
> > 
> > but should i be demonstrated wrong by how this unfolds i'm happy to
> > have
> > 
> > this extend this for another year. 
> > 
> > 
> > 
> > But for anything after that the bulk of the python2.x maintenance
> > work
> > 
> > should be left on the shoulders of companies and individuals that
> > have
> > 
> > an actual requirement for that.
> > 
> > 
> > 
> > -- Ronny
> > 
> > 
> > 
> > ___
> > 
> > pytest-dev mailing list
> > 
> > pytest-dev@python.org
> > 
> > https://mail.python.org/mailman/listinfo/pytest-dev
> > 
___
pytest-dev mailing list
pytest-dev@python.org
https://mail.python.org/mailman/listinfo/pytest-dev

Re: [pytest-dev] branch proposals - python2 support and pytest 4.0 preps

[Ronny Pfannschmidt]

Am Mo., 24. Sep. 2018 um 16:22 Uhr schrieb Bruno Oliveira <
nicodde...@gmail.com>:

> Hi Ronny,
>
> On Mon, Sep 24, 2018 at 10:29 AM Ronny Pfannschmidt <
> opensou...@ronnypfannschmidt.de> wrote:
>
>>
>> a) maintenance-python2 : this will be the branch where bugfixes for the
>> last python2 suporting versions will happen
>>
>> i intend to create it in line with the yet to be shaped plans for the
>> python2 support/maintenance branches once the poll results are reviwerd
>> and we have decided on a timeline to put into action
>>
>
> Sounds good.
>
>
>> b) removals or breakage : this will be the branch where we merge
>> breaking changes in preparation of major releases
>>
>
> Do we need this? I was thinking we would just remove the breaking changes
> in the "features" branch after 4.0 is released (for 4.0 we will turn the
> warnings into errors, removal will happen in 4.1).
>
> True, in that order its actually fine to sort out that way, my brain is a
bit hardwired to too strict semver

-- Ronny




> Cheers,
> Bruno
> ___
> pytest-dev mailing list
> pytest-dev@python.org
> https://mail.python.org/mailman/listinfo/pytest-dev
>


-- 

Red Hat GmbH, http://www.de.redhat.com/, Registered seat: Grasbrunn,
Commercial register: Amtsgericht Muenchen, HRB 153243,
Managing Directors: Charles Cachera, Michael Cunningham, Michael
O'Neill, Eric Shander
___
pytest-dev mailing list
pytest-dev@python.org
https://mail.python.org/mailman/listinfo/pytest-dev

[pytest-dev] branch proposals - python2 support and pytest 4.0 preps

[Ronny Pfannschmidt]

hi everyone,

in face of the pending larger changes for a pytest 4.0 removing various
things and for the support branching of python2 id like to propose 2
extra branches


a) maintenance-python2 : this will be the branch where bugfixes for the
last python2 suporting versions will happen

i intend to create it in line with the yet to be shaped plans for the
python2 support/maintenance branches once the poll results are reviwerd
and we have decided on a timeline to put into action

b) removals or breakage : this will be the branch where we merge
breaking changes in preparation of major releases

i'd like to get this one started soon and create according automation
to ensure we merge/move patches across bugfixes, features and the
removal/breakage branches in a timely manner

-- Ronny


___
pytest-dev mailing list
pytest-dev@python.org
https://mail.python.org/mailman/listinfo/pytest-dev

Re: [pytest-dev] [TIP] pytest Python 2.7 support (poll) (re-sent)

[Ronny Pfannschmidt]

(re-sending since i used the wrong mail first)

I refuse since its a pain to sort out GDPR compliance when self-
hosting 
that way.

public is easy, public and law abiding is a pain.

-- Ronny

Am Sonntag, den 23.09.2018, 18:57 +0200 schrieb Daniel Knüttel:
> Am Sonntag, den 23.09.2018, 08:20 -0500 schrieb Ian Stapleton
> Cordasco:
> > It's also important to note that you need to have a Twitter account
> > to
> > vote, which will probably exclude a fair number of potential
> > voters.
> > 
> 
> This would exclude for instance me. If you send me the exact
> questions
> I can recreate the poll on my personal Nexcloud server so the poll is
> truly public.
> 
> By the way: I think 2.7 support should be dropped. 

___
pytest-dev mailing list
pytest-dev@python.org
https://mail.python.org/mailman/listinfo/pytest-dev

Re: [pytest-dev] Accessing markers in pytest_generate_tests

[Ronny Pfannschmidt]

Am Freitag, den 21.09.2018, 12:44 +0100 schrieb Nikolaus Rath:
> Hello,
> 
> I am currently using code like this:
> 
> def pytest_generate_tests(metafunc, _info_cache=[]):
> # [...]
> 
> fn = metafunc.function
>   
> do_something(fn.with_backend.kwargs)
> for spec in fn.with_backend.args:
># [...]
> 
> This has started to emit a warning:
> 
> /home/nikratio/in-progress/s3ql/tests/t1_backends.py:118:
> RemovedInPytest4Warning: MarkInfo objects are deprecated as they
> contain merged marks which are hard to deal with correctly.
> Please use node.get_closest_marker(name) or node.iter_markers(name).
> Docs: https://docs.pytest.org/en/latest/mark.html#updating-code
>   for spec in fn.with_backend.args:
> 
> 
> In my case, the correction solution seems to be to use the
> get_closest_marker() method instead. However, this is defined for
> Node -
> neither the metafunc nor the metafunc.function objects have such a
> method.
> 
> What's the recommended way to access markers in
> pytest_generate_tests?

metafunc.definition.get_closest_marker(...) should do

-- Ronny

> 
> Best,
> -Nikolaus
> 
> 

___
pytest-dev mailing list
pytest-dev@python.org
https://mail.python.org/mailman/listinfo/pytest-dev

Re: [pytest-dev] Disable pushing directly to features and master branches

[Ronny Pfannschmidt]

+1

Am 6. Juli 2018 17:15:16 MESZ schrieb Nicholas Williams 
:
>+1
>
>On Fri, Jul 6, 2018 at 10:13 AM, Bruno Oliveira 
>wrote:
>
>> Hi everyone,
>>
>> GitHub has started issue warnings that the email service we use to
>notify
>> pushes to master and features will be discontinued (and we suspect it
>is
>> not working correctly either).
>>
>> Given that we now invite people who have have had a complete PR
>merged, a
>> lot of new people are getting commit rights to the repository.
>>
>> To prevent changes to "master" and "features" branches to go
>unnoticed
>> when the email service gets discontinued, I propose to disable direct
>> pushes to those branches (using the GitHub option for that).
>>
>> Opinions?
>>
>> If nobody opposes I plan to enable this by the end of the day, as it
>is
>> just a check box on GitHub's UI to revert this decision anyway.
>>
>> Cheers,
>> Bruno.
>>
>>
>>
>> ___
>> pytest-dev mailing list
>> pytest-dev@python.org
>> https://mail.python.org/mailman/listinfo/pytest-dev
>>
>>
___
pytest-dev mailing list
pytest-dev@python.org
https://mail.python.org/mailman/listinfo/pytest-dev

Re: [pytest-dev] preparing a set of breaking changes

[Ronny Pfannschmidt]

in 2010 yield tests where likely still working correctly
they where fundamentally broken ever since pytest introduced the collection
phase

-- Ronny

2018-04-11 12:46 GMT+02:00 Chris Dent :

> On Sun, 8 Apr 2018, RonnyPfannschmidt wrote:
>
> * removal of yield tests, ever since collection and test running are no
>> longer connected, their setupstate has been fundamentally broken for
>> anything but test so simple, one should use parametrize
>>
>
> Not saying it's wrong to see them go, but back in perhaps 2010 (not
> really sure of the exact time) pytest's yield tests are what made me
> fall in love with pytest.
>
> That was back when pytest was still a thing that did some collecting
> of stuff named 'test_*' that has 'assert' calls in it, and not much
> else.
>
> I loved that. All the fixtures, decorators, etc that we have now are
> nicely powerful and useful, but back when you couldn't do much in
> tests it meant that during TDD you couldn't do much in code either,
> and that was a great thing.
>
> /me raises a glass to yield tests, bon voyage
>
> --
> Chris Dent   ٩◔̯◔۶   https://anticdent.org/
> freenode: cdent tw: @anticdent
> ___
> pytest-dev mailing list
> pytest-dev@python.org
> https://mail.python.org/mailman/listinfo/pytest-dev
>
>


-- 

Red Hat GmbH, http://www.de.redhat.com/, Registered seat: Grasbrunn,
Commercial register: Amtsgericht Muenchen, HRB 153243,
Managing Directors: Charles Cachera, Michael Cunningham, Michael
O'Neill, Eric Shander
___
pytest-dev mailing list
pytest-dev@python.org
https://mail.python.org/mailman/listinfo/pytest-dev

Re: [pytest-dev] Custom reporting for asserts without comparison operators?

[Ronny Pfannschmidt]

that approach is broken in the sense, that it breaks behaviour expectations,
an return value helper, that triggers an assertion on its own is simply no
longer a return value helper, but a assertion helper

supporting it like that would result in a really bad api

instead having  assertion helper that returns a "truthy" object which can
be introspected by pytest and/or negated should be more suitable

2018-03-22 3:39 GMT+01:00 Shawn Brown <03sjbr...@gmail.com>:

> Ah. It's good to see that this has been thought about before.
>
> My motivation for asking this question was to perform my due diligence and
> make sure I wasn't missing something before moving ahead. My immediate
> need is handled by using assert_myfunc() to raise its own error
> internally--same as Floris' example. Though, it's not ideal.
>
> I know my examples have been vague as I've stripped the specifics of my
> project to focus the question specifically on pytest's behavior and I
> greatly appreciate everyone who is giving some thought to this.
>
> As Ronny mentioned, I'm sure it's possible to address this without
> user-facing AST manipulation. But I'm not familiar enough with the code
> base to see where I can best hack on the representations. However, I do
> have a working AST-based demonstration (below). This uses a fragile
> monkey-patch that is just asking for trouble so please take this for the
> experimental hack it is...
>
>
> FILE "conftest.py":
>
> import ast
> import _pytest
>
> def my_ast_prerewrite_hook(ast_assert):
> """Modifies AST of certain asserts before pytest-rewriting."""
> # Demo AST-tree manipulation (actual implemenation
> # would need to be more careful than this).
> if (isinstance(ast_assert.test, ast.Call)
> and isinstance(ast_assert.test.func, ast.Name)
> and ast_assert.test.func.id == 'myfunc'):
>
> ast_assert.test.func = ast.Name('assert_myfunc', ast.Load())
>
> return ast_assert
>
> # UNDESIRABLE MONKEY PATCHING!!!
> class ModifiedRewriter(_pytest.assertion.rewrite.AssertionRewriter):
> def visit_Assert(self, assert_):
> assert_ = my_ast_prerewrite_hook(assert_)  # <- PRE-REWRITE
> HOOK
> return super(ModifiedRewriter, self).visit_Assert(assert_)
>
> def rewrite_asserts(mod, module_path=None, config=None):
> ModifiedRewriter(module_path, config).run(mod)
>
> _pytest.assertion.rewrite.rewrite_asserts = rewrite_asserts
>
>
> FILE "test_ast_hook_approach.py":
>
> import pytest
>
> # Test helpers.
> def myfunc(x):
> return x == 42
>
> def assert_myfunc(x):
> __tracebackhide__ = True
> if not myfunc(x):
> msg = 'custom report\nmulti-line output\nmyfunc({0}) failed'
> raise AssertionError(msg.format(x))
> return True
>
> # Test cases.
> def test_1passing():
> assert myfunc(42)
>
> def test_2passing():
> assert myfunc(41) is False
>
> def test_3passing():
> with pytest.raises(AssertionError) as excinfo:
> assert myfunc(41)
> assert 'custom report' in str(excinfo.value)
>
> def test_4failing():
> assert myfunc(41)
>
>
> Running the above test gives 3 passing cases and 1 failing case (which
> uses the custom report). Also, test_2passing() checks for "is False"
> instead of just "== False" which I think would be wonderful to support as
> it removes all caveats for the user (so users get a real False when they
> expect False, instead of a Falsey alternative). Also, if I were going to
> use AST manipulation like this, I would probably reference assert_myfunc()
> by attaching it as a private attribute to myfunc() itself -- and then
> reference it with ast.Attribute() node instead of an ast.Name(). But again,
> solving this without AST manipulation could be better in many ways.
>
> --Shawn
>
>
> On Mon, Mar 19, 2018 at 1:59 PM, Ronny Pfannschmidt <
> i...@ronnypfannschmidt.de> wrote:
>
>> hi everyone,
>>
>> this is just about single value assertion helpers
>>
>> i logged an feature request about that a few year back
>> see https://github.com/pytest-dev/pytest/issues/95 -
>>
>> so basically this use-case was known since 2011 ^^ and doesn't require
>> ast rewriting lice macros,
>> just proper engineering of the representation and handling of single
>> values in the assertion rewriter.
>>
>> -- Ronny
>>
>>
>> Am 19.03.2018 um 15:13 schrieb holger krekel:
>> 

Re: [pytest-dev] mark fix-up major milestone, please review

[Ronny Pfannschmidt]

again - please show me those changes!

-- Ronny

2018-03-20 19:33 GMT+01:00 Florian Schulze <florian.schu...@gmx.net>:

> On 20 Mar 2018, at 16:11, Ronny Pfannschmidt wrote:
>
> just a quick note - the markers pr as far as i understood it does not
>> qualify for a 4.0 since the basci apis are bckward compatible and work as
>> expected, if we would make it 4.0 worthy, then by dropping the old cruft
>>
>
> In my opinion the change in transfer behaviour makes it 4.0, because it
> *will* affect people. It changed things in devpi-server which necessitates
> (small) changes. For others it might have way more far reaching effects.
>
> Regards,
> Florian Schulze
>
>
> 2018-03-20 16:03 GMT+01:00 Florian Schulze <florian.schu...@gmx.net>:
>>
>> On 20 Mar 2018, at 15:07, Floris Bruynooghe wrote:
>>>
>>> On Tue, Mar 20 2018, Ronny Pfannschmidt wrote:
>>>
>>>>
>>>> 2018-03-20 9:18 GMT+01:00 Floris Bruynooghe <f...@devork.be>:
>>>>
>>>>>
>>>>> On Mon, Mar 19 2018, Ronny Pfannschmidt wrote:
>>>>>>
>>>>>> I also did deprecate markinfo attributes,
>>>>>>> so everyone using them will get deprecation warnings.
>>>>>>>
>>>>>>>
>>>>>> That's a lot of people probably.  How long are we giving users for
>>>>>> this?
>>>>>> ​
>>>>>>
>>>>>>
>>>>>> ​the support for accessing them can be kept for quite a while,
>>>>> everyone using them will be told to use the new api
>>>>> i would like to remove it at the beginning of 2019
>>>>>
>>>>>
>>>> Ok, they're currently marked as "deprecated in 4.0".  So we're not
>>>> releasing 4.0 until then?  Or are we just keeping our options open here
>>>> and extending a deprecation is easier then reducing it?
>>>>
>>>>
>>> I think the marker PR already qualifies for a 4.0, so I would extend the
>>> deprecations.
>>>
>>>
>>> Thanks!  Could you give an example of a marker transfer bug?  I've never
>>>
>>>> run into those myself so I'm not sure I understand what this is.
>>>>
>>>>
>>> In devpi-server we have test classes that inherit from another test
>>> class.
>>> The derived one overwrites one fixture (for example testing through nginx
>>> or a devpi replica instead of directly against devpi-server). Because
>>> some
>>> of these fixtures are expensive, I want to mark the inherited class as
>>> "slow". Currently that mark is transferred to the base class and there is
>>> no other way to mark only the test functions on the derived class as
>>> slow.
>>> So currently the base class is also marked as slow. The PR fixes that.
>>>
>>> Regards,
>>> Florian Schulze
>>>
>>>
>>
>>
>> --
>>
>> Red Hat GmbH, http://www.de.redhat.com/, Registered seat: Grasbrunn,
>> Commercial register: Amtsgericht Muenchen, HRB 153243,
>> Managing Directors: Charles Cachera, Michael Cunningham, Michael
>> O'Neill, Eric Shander
>>
>
>
>


-- 

Red Hat GmbH, http://www.de.redhat.com/, Registered seat: Grasbrunn,
Commercial register: Amtsgericht Muenchen, HRB 153243,
Managing Directors: Charles Cachera, Michael Cunningham, Michael
O'Neill, Eric Shander
___
pytest-dev mailing list
pytest-dev@python.org
https://mail.python.org/mailman/listinfo/pytest-dev

Re: [pytest-dev] mark fix-up major milestone, please review

[Ronny Pfannschmidt]

just a quick note - the markers pr as far as i understood it does not
qualify for a 4.0 since the basci apis are bckward compatible and work as
expected, if we would make it 4.0 worthy, then by dropping the old cruft

-- Ronny

2018-03-20 16:03 GMT+01:00 Florian Schulze <florian.schu...@gmx.net>:

> On 20 Mar 2018, at 15:07, Floris Bruynooghe wrote:
>
> On Tue, Mar 20 2018, Ronny Pfannschmidt wrote:
>>
>> 2018-03-20 9:18 GMT+01:00 Floris Bruynooghe <f...@devork.be>:
>>>
>>>> On Mon, Mar 19 2018, Ronny Pfannschmidt wrote:
>>>>
>>>>> I also did deprecate markinfo attributes,
>>>>> so everyone using them will get deprecation warnings.
>>>>>
>>>>
>>>> That's a lot of people probably.  How long are we giving users for this?
>>>> ​
>>>>
>>>>
>>> ​the support for accessing them can be kept for quite a while,
>>> everyone using them will be told to use the new api
>>> i would like to remove it at the beginning of 2019
>>>
>>
>> Ok, they're currently marked as "deprecated in 4.0".  So we're not
>> releasing 4.0 until then?  Or are we just keeping our options open here
>> and extending a deprecation is easier then reducing it?
>>
>
> I think the marker PR already qualifies for a 4.0, so I would extend the
> deprecations.
>
>
> Thanks!  Could you give an example of a marker transfer bug?  I've never
>> run into those myself so I'm not sure I understand what this is.
>>
>
> In devpi-server we have test classes that inherit from another test class.
> The derived one overwrites one fixture (for example testing through nginx
> or a devpi replica instead of directly against devpi-server). Because some
> of these fixtures are expensive, I want to mark the inherited class as
> "slow". Currently that mark is transferred to the base class and there is
> no other way to mark only the test functions on the derived class as slow.
> So currently the base class is also marked as slow. The PR fixes that.
>
> Regards,
> Florian Schulze
>



-- 

Red Hat GmbH, http://www.de.redhat.com/, Registered seat: Grasbrunn,
Commercial register: Amtsgericht Muenchen, HRB 153243,
Managing Directors: Charles Cachera, Michael Cunningham, Michael
O'Neill, Eric Shander
___
pytest-dev mailing list
pytest-dev@python.org
https://mail.python.org/mailman/listinfo/pytest-dev

Re: [pytest-dev] mark fix-up major milestone, please review

[Ronny Pfannschmidt]

2018-03-20 15:07 GMT+01:00 Floris Bruynooghe <f...@devork.be>:

> On Tue, Mar 20 2018, Ronny Pfannschmidt wrote:
>
> > 2018-03-20 9:18 GMT+01:00 Floris Bruynooghe <f...@devork.be>:
> >> On Mon, Mar 19 2018, Ronny Pfannschmidt wrote:
> >> > I also did deprecate markinfo attributes,
> >> > so everyone using them will get deprecation warnings.
> >>
> >> That's a lot of people probably.  How long are we giving users for this?
> >> ​
> >>
> >
> > ​the support for accessing them can be kept for quite a while,
> > everyone using them will be told to use the new api
> > i would like to remove it at the beginning of 2019
>
> Ok, they're currently marked as "deprecated in 4.0".  So we're not
> releasing 4.0 until then?  Or are we just keeping our options open here
> and extending a deprecation is easier then reducing it?
>

​exending is easier than reducing. - but im not opposed to killing it
earlier​



>
> >> > as far as i'm concerned, markinfo attributes where never ever a
> correct
> >> way
> >> > to handle distinct marks and quite a few bugs in pytest came from
> using
> >> > combined marks in markinfo instead of distinct marks.
> >>
> >> A short summary of these issues would help loads :)
> >>
> > ​basically MarkInfo objects are subject to marker transfer bugs, marker
> > smearing and everything wrong with marks these days
> > they are one of holgers infamous minimal changes that basically ensured
> we
> > never ever had correctly working marks
> > from the time we had support for more than one marker of the same name,
> and
> > it got worse by the addition of marker transfers
> > (for context - pytest marks started as thing to update test function
> > __dict__ with its keyword arguments,
> > they never got de-tangled from that messy legacy, and that was a major
> > source of really bad bugs)
>
> Thanks!  Could you give an example of a marker transfer bug?  I've never
> run into those myself so I'm not sure I understand what this is.  I
> assume something like this will trigger weird cases:
>
> @pytest.mark.mark0
> class Foo:
>
> @pytest.mark.mark1
> def test_foo(self):
> pass
>
> @pytest.mark.mark0('foo', a='a')
> def test_bar(self):
> pass
>
> So the new API to inspect this is (in some pseudo-code like fashion):
>
> .get_marker('mark0') -> Mark(name='mark0')
> .get_marker('mark1') -> Mark(name='mark1')
> .get_marker('mark0') -> ??
> list( [Mark(name='mark0')]
> list( ??
>
>
​class TestA(object):
   def test_fun(self):
  pass


@pytest.mark.evil
class TestB(TestA):
  pass

-> after collection TestA.test_fun will have a evil marker​





> Also, can I iterate over all the markers on a node?
>
>
> ​for now, explicitly not,

i'm open to introducing it when someone demonstrates a real practical
use-case​
--
​ Ronny​



> Thanks for educating me!
> Floris
>



-- 

Red Hat GmbH, http://www.de.redhat.com/, Registered seat: Grasbrunn,
Commercial register: Amtsgericht Muenchen, HRB 153243,
Managing Directors: Charles Cachera, Michael Cunningham, Michael
O'Neill, Eric Shander
___
pytest-dev mailing list
pytest-dev@python.org
https://mail.python.org/mailman/listinfo/pytest-dev

Re: [pytest-dev] mark fix-up major milestone, please review

[Ronny Pfannschmidt]

2018-03-20 9:18 GMT+01:00 Floris Bruynooghe <f...@devork.be>:

> Hi Ronny,
>
> On Mon, Mar 19 2018, Ronny Pfannschmidt wrote:
>
> > Hi everyone,
> >
> > in https://github.com/pytest-dev/pytest/pull/3317 i introduced a new
> way to
> > store marks and aslo consistently use it (this fixed a few bugs pytest
> > dragged along since years)
>
> I've spent a while reading the PR but to be honest it's kind of hard to
> know how sane things are.  It looks ok, but I don't have a view of the
> larger picture.
>
> Are there somewhere some notes about where the marks come from, what the
> problems with them are and the vision of how the problems are going to
> be solved and what the end-state will look like?
>
> For example from the current PR it's not obvious how users are meant to
> be using marks.  You still apply them using @pytest.mark.name as before,
> but how are we supposed to access them?  How are we setting them
> pragmatically?
>

​the way for declaring them is still the same
the addmarker apis still work the same​




>
> > I also did deprecate markinfo attributes,
> > so everyone using them will get deprecation warnings.
>
> That's a lot of people probably.  How long are we giving users for this?
> ​
>

​the support for accessing them can be kept for quite a while,
everyone using them will be told to use the new api
i would like to remove it at the beginning of 2019

​
>
>
> > as far as i'm concerned, markinfo attributes where never ever a correct
> way
> > to handle distinct marks and quite a few bugs in pytest came from using
> > combined marks in markinfo instead of distinct marks.
>
> A short summary of these issues would help loads :)
>
​basically MarkInfo objects are subject to marker transfer bugs, marker
smearing and everything wrong with marks these days
they are one of holgers infamous minimal changes that basically ensured we
never ever had correctly working marks
from the time we had support for more than one marker of the same name, and
it got worse by the addition of marker transfers
(for context - pytest marks started as thing to update test function
__dict__ with its keyword arguments,
they never got de-tangled from that messy legacy, and that was a major
source of really bad bugs)



also they are part of a inconsistent return value issues that previously
plaqued get_marker​,
now get_markers returns a reasonably correct MarkInfo and find_markers is
finally an api that provides basic correct values

cheers,
Ronny



>
>
> Cheers,
> Floris
>



-- 

Red Hat GmbH, http://www.de.redhat.com/, Registered seat: Grasbrunn,
Commercial register: Amtsgericht Muenchen, HRB 153243,
Managing Directors: Charles Cachera, Michael Cunningham, Michael
O'Neill, Eric Shander
___
pytest-dev mailing list
pytest-dev@python.org
https://mail.python.org/mailman/listinfo/pytest-dev

[pytest-dev] mark fix-up major milestone, please review

[Ronny Pfannschmidt]

Hi everyone,

in https://github.com/pytest-dev/pytest/pull/3317 i introduced a new way to
store marks and aslo consistently use it (this fixed a few bugs pytest
dragged along since years)

some of the things i had to do is introduce a internal FunctionDefinition
node that's currently just being used by the collectors to give metafunc
correct access to marks.

i'm hoping to eventually elevate that in future,
but the amount of spaghetti makes that a major undertaking,
pytest is just so tightly coupled all over the place that it is suffocating
and really error inducing

I also did deprecate markinfo attributes,
so everyone using them will get deprecation warnings.

as far as i'm concerned, markinfo attributes where never ever a correct way
to handle distinct marks and quite a few bugs in pytest came from using
combined marks in markinfo instead of distinct marks.

i also changed get_marker, and starting to realize that i need to make it
return a MarkInfo again (at least one with correct data this time around)
(that's upcoming in a few)

other than that please take a look and find details to scrutinize

-- Ronny

-- 

Red Hat GmbH, http://www.de.redhat.com/, Registered seat: Grasbrunn,
Commercial register: Amtsgericht Muenchen, HRB 153243,
Managing Directors: Charles Cachera, Michael Cunningham, Michael
O'Neill, Eric Shander
___
pytest-dev mailing list
pytest-dev@python.org
https://mail.python.org/mailman/listinfo/pytest-dev

Re: [pytest-dev] pytest 3.5 soon?

[Ronny Pfannschmidt]

Am Donnerstag, den 15.03.2018, 19:30 + schrieb Bruno Oliveira:
> On Thu, Mar 15, 2018 at 4:26 PM RonnyPfannschmidt  annschmidt.de> wrote:
> >   
> > 
> >   
> >   
> > +1
> > 
> > the next big things i will try to work on are 
> > 
> > 
> > 
> > * a new marker api and 
> > 
> >   * a actually correct config initialization
> > 
> > (the one we currently do is broken and creates bugs in
> > xdist)
> 
> Sounds good to me!
>  
> > i hope to get a part in for 3.5 but i believe most of the
> >   important things will need 3.6
> 
> I was thinking of releasing 3.5 like next week, you think you can
> squeeze something until then or would you like more time?

please dont defer a timed release for my convenience - if i fail to get
the changes in thatsa failure i can easyly accept, but i wouldn't want
to delay releases for that
cheers,Ronny
> Cheers,
> Bruno.___
pytest-dev mailing list
pytest-dev@python.org
https://mail.python.org/mailman/listinfo/pytest-dev

Re: [pytest-dev] Alias to parametrize

[Ronny Pfannschmidt]

HI,

i also like apply_params, it well in place with my desire of a more
complete rename instead of just cutting it short.

+1

for eternal old api's i would like to introduce a warning which is per
default filtered (like a future-warning), simply so plugin authors can have
a advised way of keeping up with core even if we keep some old things in
place for users

-- Ronny

2018-01-31 10:42 GMT+01:00 holger krekel :

> On Tue, Jan 30, 2018 at 22:22 -0800, Floris Bruynooghe wrote:
> > holger krekel  writes:
> >
> > > On Mon, Jan 29, 2018 at 19:08 -0800, Floris Bruynooghe wrote:
> > >> Bruno Oliveira  writes:
> > >> > A PR[1] has been submitted which adds `parameterize` as an alias to
> > >> > `parametrize`. Florian Bruhin and I are not very keen to the idea
> given
> > >> > that there is an explicit warning for it already and having
> different names
> > >> > to the same thing reduces consistency across test suites.
> > >>
> > >> So I've recently finished a (toy) plugin which I've been intending to
> > >> release as pytest-parawtf.  It's currently in the legal machine of my
> > >> employer for me to hopefully be able to release unrestricted.  You can
> > >> probably guess what it does from the name, but it basically allows a
> few
> > >> misspellings in all locations.  I actually considered allowing
> anything
> > >> matching the ``param*`` wildcard but thought while fun it would
> probably
> > >> stop people from using it.
> > >>
> > >> However the serious note in that plugin is that I think it makes sense
> > >> to use ``params``.  My reasoning is that it's easy to spell and
> already
> > >> used for fixtures: ``@pytest.fixture(params=[0, 1])``.  So why not
> > >> everywhere else:  ``@pytest.mark.params('a', [0, 1])``,
> > >> ``metafunc.params(...)``.  So to be honest I think we should migrate
> to
> > >> that and still disallow the other variants.  It would mean I don't get
> > >> to release my fun plugin but whatever.
> > >
> > > i initially meant to write my skepticism wrt to going the
> > > "alternative spellings" route but FWIW i do like "params" as it also
> matches
> > > accessing a parameter via "request.param" inside fixture functions. For
> > > ``metafunc.X`` i rather expect X to be a verb, however. /me fiddles
> with
> > > the parameters of what he supposes is a time-machine ...
> > >
> > > That being said i don't like the idea of making tons of existing code
> > > throw warnings, let alone having "pytest.mark.parametrize" erroring out
> > > in future pytest versions. I guess i am aware of too many existing code
> > > bases (and written and printed tutorials and books) which would
> > > suffer. Independently from the question at hand I recommend to be
> > > careful with the notion of "people can just rename their code".
> >
> > For metafunc having a verb sort of makes sense.  But also the
> > consistency argument is strong.  You could try to go the .apply_params()
> > or something similar route I guess but not sure I'd prefer this over the
> > bare .params().
>
> I like metafunc.apply_params().
>
> > Also, I don't think there is any reason to start issuing warnings for
> > something like this.  We can and should support parametrize for eternity
> > without ever issuing warnings or anything like that.  Only a note in the
> > documentation to suggest one may prefer to use the params variant in new
> > code if one doesn't feel strongly themselves.  Alternatively we could
> > leave it as a plugin and refer to that in the docs.  If it proves
> > popular (not sure how you can know that these days, but anyway) then it
> > could still be merged into the core at some point.
>
> For past renamings we simply changed the docs to use the preferred version
> and maybe added a note about the old spelling.  For example, before
> ``metafunc.parametrize`` was introduced ~6y ago pytest docs advertised
> ``metafunc.addcall`` which still works today. It was finally deprecated
> in pytest-3.3 and its removal will probably still break existing code.
> However, here keeping backward-compat compatibility complicates the
> intricate parametrization/fixture interaction implementation. Therefore
> I guess it's warranted to remove it eventually because it relaxes
> refactoring
> constraints.  By comparison, renaming parametrize() to apply_params() is
> a trivial thing to support in a backward compatible way (``parametrize =
> apply_params``).
>
> IMHO the new spelling should be part of core proper and could even come
> with a 3.5 (or 3.6 ...) because it doesn't break anything.
>
> holger
>
> > On that last thing there is one caveat, hinted at by Brian.  The plugin
> > does not play nice.  I don't have the code with me as I'm traveling but
> > IIRC it uses at least one underscored method/attribute and even
> > everything else it does is outright horrible and can't be reasonably
> > considered part of the public pytest API.
> >
> > Cheers,
> > Floris
> 

Re: [pytest-dev] Alias to parametrize

[Ronny Pfannschmidt]

the alt_spellings is actually a list of wrong spellings that triggers
errors - the reason being that the word as different spellings in british
and american English

if we actually change the word i would like to see something completely
different, not just some  short-cutting

-- Ronny

2018-01-30 6:28 GMT+01:00 Matt Griswold :

> * Floris Bruynooghe  [180129 19:08 -0800]:
> > However the serious note in that plugin is that I think it makes sense
> > to use ``params``.  My reasoning is that it's easy to spell and
> > already used for fixtures: ``@pytest.fixture(params=[0, 1])``.  So
> > why not everywhere else:  ``@pytest.mark.params('a', [0, 1])``,
> > ``metafunc.params(...)``.  So to be honest I think we should migrate
> > to that and still disallow the other variants.  It would mean I don't
> > get to release my fun plugin but whatever.
>
> That makes a lot of sense to me, although I'm not a pytest developer
> and have no idea what the pytest rules for making backward incompatible
> changes are.
>
> After reading this thread, I chimed in on GitHub -- aliases are almost
> never a good idea, but the fact that there's an alt_spellings list in
> the code means that it really should just be renamed. This should be as
> simple as a deprecation warning, time period, and users doing a
> s/parametrize/params/.
>
> Cheers
> ___
> pytest-dev mailing list
> pytest-dev@python.org
> https://mail.python.org/mailman/listinfo/pytest-dev
>



-- 

Red Hat GmbH, http://www.de.redhat.com/, Registered seat: Grasbrunn,
Commercial register: Amtsgericht Muenchen, HRB 153243,
Managing Directors: Charles Cachera, Michael Cunningham, Michael
O'Neill, Eric Shander
___
pytest-dev mailing list
pytest-dev@python.org
https://mail.python.org/mailman/listinfo/pytest-dev

Re: [pytest-dev] Parametrizing dependent fixtures

[Ronny Pfannschmidt]

Hi,

my understanding is, that the direct parametrization replaces the fixture
lookup for the involved tests,
which is not a planned "feature" per se, but still a neat tool to have

-- Ronny

2018-01-08 14:07 GMT+01:00 Bruno Oliveira :

> Hi Edgar,
>
> On Mon, Jan 8, 2018 at 10:32 AM Edgar Ostrowski 
> wrote:
>
>> Anyway I would like to confirm that this is valid way of using the
>> parametrize marker.
>>
>
> I did not look at the video yet, but fixture parametrization only works by
> using @pytest.fixture(params=...). Markers don't do anything when applying
> to fixtures.
>
> Hope that clarifies things!
>
> Cheers,
> Bruno.
>
> ___
> pytest-dev mailing list
> pytest-dev@python.org
> https://mail.python.org/mailman/listinfo/pytest-dev
>
>


-- 

Red Hat GmbH, http://www.de.redhat.com/, Registered seat: Grasbrunn,
Commercial register: Amtsgericht Muenchen, HRB 153243,
Managing Directors: Charles Cachera, Michael Cunningham, Michael
O'Neill, Eric Shander
___
pytest-dev mailing list
pytest-dev@python.org
https://mail.python.org/mailman/listinfo/pytest-dev

Re: [pytest-dev] Proposal: use milestones again for features/deprecations/removals

[Ronny Pfannschmidt]

+1 from me

2018-01-05 2:12 GMT+01:00 Bruno Oliveira :

> Hi,
>
> We used milestones in the past to track what would go in each release,
> including bugs and new features, but we have not been using them anymore
> and I think the reason is because we never usually kept that promise: if we
> deemed a release should happen soon we just moved all issues forward or
> removed the milestone from them altogether.
>
> I propose we start using milestones again, but only for two reasons:
>
> * **internal** planning of new features: we should use milestones as an
> internal guide of what *should* go into the next feature release. This is
> not a promise to users, only for us to manage what we think should go into
> the next release core developer's time allowing. For example, in my mind we
> should change the default logging options [1], but this is not really
> defined anywhere except in my head. I would like to use milestones to track
> that intent.
>
> * **promise** of deprecation and removal of old features: we have been
> using a manual deprecation roadmap [2], but the question of how to keep
> issues in sync has been nagging in the back of my head. We should track
> deprecation and removals in the milestones, but we must be sure to followup
> with them before a feature release is complete. It is important to follow
> with our policy of deprecation/two minor issues/removal.
>
> The idea is to, before a feature release, we check the the issues assigned
> to that milestone:
>
>  * for open features, we can decide to ping the developer if they want
> some more time to get that into that next feature release, otherwise we
> move it to the next milestone;
> * for open deprecation/removal issues, we have to make sure to close them
> before moving with the release.
>
> IMHO, milestones should be created only for feature releases; milestones
> for minor releases don't make much sense in our current development
> methodology: we can issue bug-fix releases as quickly as we want/need to,
> so no feature release should really be blocked by a bug, we can always
> issue a bug-fix right after a certain bug is dealt with.
>
> This is an attempt to help our planning and strengthen our
> deprecation/removal policy.
>
> Thoughts?
>
> [1] https://github.com/pytest-dev/pytest/issues/3013
> [2] https://docs.pytest.org/en/latest/backwards-compatibility.html
>
>
>
> ___
> pytest-dev mailing list
> pytest-dev@python.org
> https://mail.python.org/mailman/listinfo/pytest-dev
>
>


-- 

Red Hat GmbH, http://www.de.redhat.com/, Registered seat: Grasbrunn,
Commercial register: Amtsgericht Muenchen, HRB 153243,
Managing Directors: Charles Cachera, Michael Cunningham, Michael
O'Neill, Eric Shander
___
pytest-dev mailing list
pytest-dev@python.org
https://mail.python.org/mailman/listinfo/pytest-dev

Re: [pytest-dev] [proposal] experiment with adapting gitmate.io for automating issue maintenance/triaging tasks

[Ronny Pfannschmidt]

i propose that unless someone vetos, i'll take a look into activating
it for pytest-dev/pytest on monday.
-- Ronny
Am Freitag, den 08.12.2017, 18:12 + schrieb Bruno Oliveira:
> Howdy Ronny,
> 
> On Fri, Dec 8, 2017 at 2:36 PM Ronny Pfannschmidt <opensource@ronnypf
> annschmidt.de> wrote:
> > Hi Everyone,
> > 
> > 
> > 
> > a while back the people behind gitmate.io did interview me to
> > expand
> > 
> > their perspective with focus on how pytest does things as well as
> > how i
> > 
> > do certain things at work,
> > 
> > 
> > 
> > they also provided me with a basic example on what i would have
> > done
> > 
> > for pytest:
> > 
> > 
> > 
> > https://gitmate.io/report/https:%2F%2Fgithub.com%2Fpytest-dev%2Fpyt
> > est
> > 
> > 
> > 
> > i beleive it would help to free up a lof of volunteer time from
> > issue
> > 
> > triaging to start and use such a tool.
> 
> Looking at the features page[1] it indeed does seem helpful. 
> 
> I'm definitely +1 to use GitMate if it will help us cut down on issue
> triaging. We can always disable it later if it is not working out for
> us.
> 
> [1] https://gitmate.io/features   
> 
> Cheers,Bruno 
> > 
> > -- Ronny
> > 
> > ___
> > 
> > pytest-dev mailing list
> > 
> > pytest-dev@python.org
> > 
> > https://mail.python.org/mailman/listinfo/pytest-dev
> > ___
pytest-dev mailing list
pytest-dev@python.org
https://mail.python.org/mailman/listinfo/pytest-dev

[pytest-dev] [proposal] experiment with adapting gitmate.io for automating issue maintenance/triaging tasks

[Ronny Pfannschmidt]

Hi Everyone,

a while back the people behind gitmate.io did interview me to expand
their perspective with focus on how pytest does things as well as how i
do certain things at work,

they also provided me with a basic example on what i would have done
for pytest:

https://gitmate.io/report/https:%2F%2Fgithub.com%2Fpytest-dev%2Fpytest

i beleive it would help to free up a lof of volunteer time from issue
triaging to start and use such a tool.

-- Ronny
___
pytest-dev mailing list
pytest-dev@python.org
https://mail.python.org/mailman/listinfo/pytest-dev

Re: [pytest-dev] pytest _pytest/mark.MarkMapping behavior

[Ronny Pfannschmidt]

Am Montag, den 04.12.2017, 20:29 +0300 schrieb Yury Krasouski:
> Hi Ronny,
> 
> Many thanks for explanation!
> 
> Got this idea.
> 
> I am not sure that you are right person for this question. But could
> you do a favor and suggest a prefirable way for extraction test
> marks?

right now there is literally no sane way to extract the actual marks

however since you seem to be interested only in the names, the closest
thing is 

[k for k in item.keywords if item.get_marker(k) is not None and k not
in self.ignored_tags]

-- Ronny


> 
> At the current moment this looks like:
> > mark_plugin = test_item.config.pluginmanager.getplugin('mark')
> > if mark_plugin:
> > keywords = test_item.keywords
> > marks =
> mark_plugin.MarkMapping.from_keywords(keywords).own_mark_names
> > return [m for m in marks if m not in self.ignored_tags]
> 
> In other words I need a list of marks assigned with test item (test).
> 
> P.S. Or I need to duplicate logic in our plug-in from `from_keywords`
> class method?
> 
> Thank you a lot,
> Yury
> 
> 
> 2017-12-04 19:30 GMT+03:00 RonnyPfannschmidt  hmidt.de>:
> > 
> > Am 04.12.2017 um 16:23 schrieb Yury Krasouski:
> > > Hello Team,
> > > 
> > > To begin with, I would like to say "Thank You" for great tools.
> > > 
> > > I am writing here to ask question about _pytest/mark.MarkMapping
> > > behavior which was used in one plug-in. I noted that API is
> > > changed a little what produced issue like this: 
> > > https://github.com/reportportal/agent-python-pytest/issues/37
> > > 
> > > The fix is simple at first look: just replace _marks to
> > > own_mark_names. But I wonder about inconvenient behavior of 
> > > 
> > > > def __getitem__(self, name):
> > > > return name in self.own_mark_names
> > > 
> > > I would expect to call list(MarkMapping) which will return list
> > > of mark names, but instead this returns infinite iterator which
> > > produced False (or True in some cases). the im
> >  
> > > What is the reason for such behavior?
> > > 
> >  the implementation of MarkMapping is only complete enough to
> > fulfill its internal use case
> > it has no correct iteration behavior implemented, thus the fallback
> > of python breaks
> > 
> > any use of this class outside of the code path it was hacked up for
> > is likely completely incorrect
> > 
> > -- Ronny
> > 
> > 
> > > Thanks,
> > > Yury
> > > 
> > > 
> > > ___
> > > pytest-dev mailing list
> > > pytest-dev@python.org
> > > https://mail.python.org/mailman/listinfo/pytest-dev
> >  
> 
> 
___
pytest-dev mailing list
pytest-dev@python.org
https://mail.python.org/mailman/listinfo/pytest-dev

Re: [pytest-dev] marks - proposals for a new api and a path forward

[Ronny Pfannschmidt]

Hi Brian,

good call, i should extend this writing to it makes sens


what i imagine is an api like this:

node.find_marks() -> iterates over all marks of all nodes
node.find_marks('name') -> iterates over all marks that have a name
node.find_marks(SomeType) -> iterates over all marks that are instaces
of the type


node.find_marks_with_nodes(...) same as find_marks, however iterate
over tuples of (node, mark) where nodeis the owning node and mark is
the mark object.


node.push_mark(markobj) -> pushes a mark to a node, always requires a
mark object wither taken from pytest.mark or a new style one

following up the evaluation of skip marksfor example would look like
this:

for mark in node.find_marks('skip'):
   if eval_mark(node, mark):
  pytest.skip(mark.args)


a more complex marker could be wored the following


for orgin, blocker in node.find_marks_with_node(Blocker):
   blocker.maybe_trigger_outcome(orgin=orgin, current=node)
  


as for putting those marks on nodes,
i would just use pytest.mark(Foo(a=1. b=2) as the deorator

cheers, Ronny

Am Samstag, den 26.08.2017, 09:30 -0700 schrieb Brian Okken:
> I'd personally like to see an example to show the new API proposal.
> How would it look to a user? How would it look to a plugin dev?
> 
> - Brian 
> 
> Sent from my iPhone
> 
> > On Aug 25, 2017, at 7:13 AM, RonnyPfannschmidt  > nnschmidt.de> wrote:
> > 
> > Hi everyone,
> > 
> > as far as i am concerned, we cant hope to safe the current mark
> > api,
> > 
> > Node.get_marker is just a hack looking into keywords (which is a
> > legacy
> > half broken concept and the base of marks on nodes and why they are
> > so
> > broken
> > 
> > Node.add_markers is just plain wrong, and by plain wrong i mean
> > totally
> > plain wrong
> > 
> > 
> > so in order to move forward, i'd like to leave all those messy
> > pieces in
> > place and just deprecate them, so we can remove them much later
> > 
> > 
> > going forward i'd like to introduce 2 things to nodes
> > 
> > 1. a list of their *own* markers, as a subtype of list ensuring
> > mark
> > decroators are correctly unpacked, that list would be the new per-
> > node api
> > 
> > 2. a function to iterate all marks of a node and its parents,
> > optionally
> > filtered by name,
> > 
> > yielding tuples of (mark, node)
> > 
> > 
> > once that is done almost all incorrect mark usages can be fixed
> > relatively sanely
> > 
> > afterwards going forward i'd like to introduce class based marks,
> > where instead of using a string and random data, we get to use
> > instances
> > of clearly defined classes as markers,
> > 
> > going for class based markers has various massive advantages
> > 
> > a) ability to use inheritance when searching
> > b) name-spacing is solved by python itself
> > 
> > -- Ronny
> > ___
> > pytest-dev mailing list
> > pytest-dev@python.org
> > https://mail.python.org/mailman/listinfo/pytest-dev
___
pytest-dev mailing list
pytest-dev@python.org
https://mail.python.org/mailman/listinfo/pytest-dev

Re: [pytest-dev] Doing pre-releases (was: Re: Help testing 3.2.0 release (part 2))

[Ronny Pfannschmidt]

we should mirror borgbackup in that regard

https://borgbackup.readthedocs.io/en/stable/changes.html#changelog
materializes releases candidates

we can do a automation around that as well

i wanted to propose adding a travis deploy that uploads release proposals
with materialized changelogs anyway
so that doing a release would be as simple as doing a merge form the ui

2017-07-31 14:03 GMT+02:00 Florian Bruhin :

> On Mon, Jul 31, 2017 at 11:59:32AM +, Bruno Oliveira wrote:
> > > (btw - I feel like everyone's life would be easier if we'd just push
> > > release canditates to PyPI which are installable with --pre. Then we
> can
> > > also simply do an rc2 in cases like this)
> > >
> >
> > Hmmm that does sound like a good idea at first. Two things came to my
> mind
> > though:
> >
> > 1. Doesn't tox install dependencies with --pre? If that's true then tox
> > users would install the release candidate by default.
>
> Not by default, only when you tell it to:
> http://tox.readthedocs.io/en/latest/config.html#confval-
> pip_pre=True%7CFalse(default)
> 
>
> > 2. Our release process doesn't account for it today, so we would have to
> > review it (specially changelog wise I think).
>
> What would change about changelogs? You could still just finalize the
> changelog with the final release, I think.
>
> Florian
>
> --
> https://www.qutebrowser.org  | m...@the-compiler.org (Mail/XMPP)
>GPG: 916E B0C8 FD55 A072  | https://the-compiler.org/pubkey.asc
>  I love long mails!  | https://email.is-not-s.ms/
>
> ___
> pytest-dev mailing list
> pytest-dev@python.org
> https://mail.python.org/mailman/listinfo/pytest-dev
>
>


-- 

Red Hat GmbH, http://www.de.redhat.com/, Registered seat: Grasbrunn,
Commercial register: Amtsgericht Muenchen, HRB 153243,
Managing Directors: Charles Cachera, Michael Cunningham, Michael
O'Neill, Eric Shander
___
pytest-dev mailing list
pytest-dev@python.org
https://mail.python.org/mailman/listinfo/pytest-dev

Re: [pytest-dev] the potential need to release 4.0 instead of 3.1, proposal

[Ronny Pfannschmidt]

(sending again due to prior sender typo)

given the rightfully reasserted constraints that seems a reasonable
course of action,

i'd prefer to keep it reopened instead of won't fix,
and i'd like to see a revising of the deprecation policy,

since as things as
https://github.com/pytest-dev/pytest/labels/mark-issue are impossible to
fix without being able to break things in a sensible way (its just too
much of a mess)

-- Ronny
Am 18.05.2017 um 22:05 schrieb Bruno Oliveira:
>
>
> On Thu, May 18, 2017 at 2:25 PM Floris Bruynooghe  > wrote:
>
>
> My main objection was purely on the fact that we basically disobey the
> deprecation policy right after introducing it by doing this. 
>
>
> Hmm you are right, I think this is the central point: introducing this
> change is known to possibly break things, so we should obey our
> deprecation policy of at least two minor versions before introducing
> such a change, so it can't get out in the next release regardless if
> it it is 4.0 or 3.1.
>
> If we do
> go with Ronny's approach of just bumping the version number when
> breaking backwards compat (which is what setuptools and pip and the
> like do afaik) then we really should update that policy to reflect so.
> I just thought the reason the policy was introduced was because of
> user feedback on our earlier behaviour where we usually randomly
> justified breakages because it made development more convenient.
>
>
> To be fair, this change was introduced not because it makes
> development easier, but because of a user's request
> (https://github.com/pytest-dev/pytest/issues/2147): the subtle
> differences between old style and new style classes can be annoying.
>
> Given all we've discussed so far, I think the change in the end is not
> worth the hassle and the possibility of breaking the API further. My
> proposal:
>
> 1. Drop the new-style class changes (merge #2414).
> 2. Close the original user request
> (https://github.com/pytest-dev/pytest/issues/2147) as "won't fix",
> detailing the reasons as we discussed here.
> 3. Release 3.1. \o/
>
> What do you guys say? Ronny?
>
> Cheers,
>
>
> ___
> pytest-dev mailing list
> pytest-dev@python.org
> https://mail.python.org/mailman/listinfo/pytest-dev

___
pytest-dev mailing list
pytest-dev@python.org
https://mail.python.org/mailman/listinfo/pytest-dev

Re: [pytest-dev] the potential need to release 4.0 instead of 3.1, proposal

[Ronny Pfannschmidt]

Personally ID strongly prefer a major release because we do change an api that 
is consumed,

IMHO we should do one on any case where we know beforehand,

But as we don't implement strict semver,
I opened this discussion to generate a consensus.

My general impression is that the majority  agrees on a minor release being 
sufficient, and I can go with that.

-- Ronny

Am 17. Mai 2017 19:01:34 MESZ schrieb Bruno Oliveira :
>On Tue, May 16, 2017 at 4:31 PM Brian Okken 
>wrote:
>
>> I don't get the "broke the API" part of this issue.
>> What used to work and doesn't now?
>>
>
>We changed all classes to new-style classes in order to remove the
>subtle
>differences between old style and new style, which may affect Python 2
>users.
>
>One example of such difference is that "x[0]" will raise a TypeError if
>x
>is a new-style class, and AttributeError if it is an old style class.
>Here's an real world code that broke because of this (
>https://github.com/ManageIQ/integration_tests/pull/4645/files):
>
> if hasattr(report, 'skipped'):
>  if report.skipped:
>  try:
>  contents = report.longrepr[2]
>  except AttributeError:
>  contents = str(report.longrepr)
>
>Btw, the change for this particular incompatibility was released in
>3.0.5
>mostly by accident, where TerminalRepr was changed to subclass from
>object
>in
>https://github.com/pytest-dev/pytest/commit/fbc5ba08d969adafd71ecb6fce25a1cad76bb983
>.
>
>Issue https://github.com/pytest-dev/pytest/issues/2398 contains more
>detailed info.
>
>
>Is this really significant enough to warrant bumping to 4.0.
>>
>Are you ready to follow through with the deprecating promise of
>> https://docs.pytest.org/en/latest/backwards-compatibility.html so
>soon
>> after the introduction of 3.0?
>>
>> How many people are affected by this change compared to the confusion
>of
>> having to explain to everyone what the major feature(s) of 4.0
>is(are)?
>>
>
>I believe that the purpose of this thread is to exactly discuss if this
>accidental change is enough to warrant a 4.0 release.
>
>I'm also under the impression that this will affect very few users, but
>would like to hear opinions from everyone. That accidental change from
>old
>to new-style went out in 3.0.5, if it was a major breaking point we
>would
>have heard more reports about it for now (although the current features
>branch changed *all* classes to new-style).
>
>Cheers,
>Bruno.

-- 
Diese Nachricht wurde von meinem Android-Gerät mit K-9 Mail gesendet.___
pytest-dev mailing list
pytest-dev@python.org
https://mail.python.org/mailman/listinfo/pytest-dev

[pytest-dev] moving execnet over to gh under pytest-dev

[Ronny Pfannschmidt]

Hi,

i'd like to move execnet under pytest-dev on github,

the author-map was completed a while ago, all that's missing is to move
the history and converting the issues.

i'm asking of there are any objections,
else i'll tackle it later this week.


-- Ronny

___
pytest-dev mailing list
pytest-dev@python.org
https://mail.python.org/mailman/listinfo/pytest-dev

[pytest-dev] the potential need to release 4.0 instead of 3.1, proposal

[Ronny Pfannschmidt]

Hi everyone,

with the recent discovery of 
https://github.com/pytest-dev/pytest/issues/2398 which was a result of 
accidentally introducing object as base class in pytest-2.9.1 via 
https://github.com/pytest-dev/pytest/pull/1486


since https://github.com/pytest-dev/pytest/pull/2179 , which will go 
into pytest-3.1 does the "same"
i propose considering this as breaking change (since there are subtle 
differences on the python 2 side after all)


while doing that we can also gracefully resolve the regression by 
documenting the earlier accidental change and the new expectations.


-- Ronny

___
pytest-dev mailing list
pytest-dev@python.org
https://mail.python.org/mailman/listinfo/pytest-dev

[pytest-dev] [proposal] abolishing the features branch

[Ronny Pfannschmidt]

Hi everyone,

since quite a while now we keep a lot of code away from users by leaving
it in the features branch,
more recent detail https://github.com/pytest-dev/pytest/issues/2365
where even i didn't realize we had a fix since half a year.

>From my point of view it has been demonstrated that we don't deliver
well from the features branch,
and it has been a massive pain to keep merged with master over and over.

As such i would like to stop using a features branch at all and return
to having only master.

-- Ronny

___
pytest-dev mailing list
pytest-dev@python.org
https://mail.python.org/mailman/listinfo/pytest-dev

Re: [pytest-dev] [3.1 feature] "assert not raise exception" helper: opinions about the name

[Ronny Pfannschmidt]

Please lets just use the New Name already ...

Im sick of magical knobs, they cause so much pain and suffering down the line

Am 5. April 2017 20:44:21 MESZ schrieb holger krekel <hol...@merlinux.eu>:
>Hi Bruno,
>
>thanks for going through user-testing, good idea!
>
>On Wed, Apr 05, 2017 at 18:19 +, Bruno Oliveira wrote:
>> Hi Ronny, Holger, all,
>> 
>> On Wed, Apr 5, 2017 at 1:31 PM holger krekel <hol...@merlinux.eu>
>wrote:
>> 
>> > On Wed, Apr 05, 2017 at 17:25 +0200, Ronny Pfannschmidt wrote:
>> > > while experimenting i learned of the fun fact that None is a
>"valid
>> > > exception type"
>> > > for except clauses on at least python 2.7
>> > > however on python3 it is invalid and a type error,
>> >
>> 
>> I agree with Florian in that the Python behavior for try/except None
>should
>> not really be an argument in favor or against pytest.raises(None),
>given
>> that try/except None is clearly an accident of implementation which
>has
>> been fixed in Python 3.
>> 
>> > since the usage patterns of python don't hold such a case,
>> > > i'd like to use a distinct building block for expressing it in
>order to
>> > > match the semantics of the language closer
>> >
>> > several people said however that "with pytest.raises(None): ..."
>reads
>> > good to them.
>> >
>> 
>> I decided to go around the office and do a small poll, asking my
>colleagues
>> what they thought "pytest.raises(None)" meant when shown different
>pieces
>> of code.
>> 
>> Example 1:
>> 
>> def test():
>> with pytest.raises(None):
>> foo()
>> 
>> Overall answers/thoughts:
>> 
>> 1. "I expect pytest.raises(None) to assert that an exception of *any*
>type
>> is raised"
>> 2. "I expect pytest.raises(None) to assert that no exception will be
>raised
>> by the block"
>> 3. "Expect that foo() should raise None? Wait, is that possible?" (it
>isn't)
>> 4. "I think pytest.raise(None) should always be an error, seems like
>it
>> could let an error slip through""
>> 
>> When showing this example:
>> 
>> @pytest.mark.parametrize('v, exc', [
>> ('', ValueError),
>> (1, None),
>> ])
>> def test(v, exc):
>> with pytest.raises(exc):
>> validate_int(v)
>> 
>> Things then made more sense everyone, but most people still thought
>it
>> weird/surprising and another person still preferred that
>> pytest.raises(None) to immediately throw an explicit error about None
>not
>> being accepted (and that an exception type should be used instead).
>
>Hum, wondering what about a "pytest.NoExceptionRaised" as a special
>value:
>
> @pytest.mark.parametrize('v, exc', [
> ('', ValueError),
> (1, pytest.NoExceptionRaised),
> ])
> def test(v, exc):
> with pytest.raises(exc):
> validate_int(v)
>
>If it makes some sense to you could you ask your colleagues 
>how they feel about that?  It also means that if someone
>just looks at the pytest.* namespace content there is
>confusing "pytest.do_not_raise" as a general helper.
>
>best,
>holger
>
>> 
>> When shown the "pytest.do_not_raise" alternative most people liked it
>> because it is explicit, there's no guessing about what it means and
>it is
>> easy to find in the documentation, albeit a little more verbose.
>> 
>> At first I was also convinced that the semantics of
>pytest.raises(None)
>> would be obvious, but it seems that's not the case (at least in my
>small
>> poll of around the office).
>> 
>> Given all that I'm now leaning towards going through the safe route
>of
>> being more explicit albeit more verbose.
>> 
>> What do others think?
>> 
>> Cheers,
>> Bruno.
>> 
>> 
>> >
>> > holger
>> >
>> > > - Ronny
>> > >
>> > > On 04.04.2017 19:19, holger krekel wrote:
>> > > > On Tue, Apr 04, 2017 at 15:48 +, Bruno Oliveira wrote:
>> > > >> On Fri, Mar 31, 2017 at 8:24 AM Bruno Oliveira
><nicodde...@gmail.com>
>> > wrote:
>> > > >>
>> > > >>> Hi all,
>> > > >>>
>> > > >>> On Fri, Mar 31, 2017 at 7:13 AM Vasily Kuznetsov
><kvas...@gmail.com>
>>

Re: [pytest-dev] [3.1 feature] "assert not raise exception" helper: opinions about the name

[Ronny Pfannschmidt]

I just wanted to point out a quirk,
that i stumbled upon while checking for symmetry with the python language

-- Ronny

On 05.04.2017 17:58, Florian Bruhin wrote:
> On Wed, Apr 05, 2017 at 05:49:24PM +0200, Ronny Pfannschmidt wrote:
>> i meant the except clause
> I know, I was just pointing out that there's no valid use case for
> pytest.raises(None) already, as None can never be raised.
>
> In fact, pytest.raises(None) already *does* error out, even on Python 2:
>
>   >>> pytest.raises(None)
>   Traceback (most recent call last):
> File "", line 1, in 
> File 
> "/home/florian/tmp/.venv/lib/python2.7/site-packages/_pytest/python.py", line 
> 1191, in raises
>   raise TypeError(msg % type(expected_exception))
>   TypeError: exceptions must be old-style classes or derived from 
> BaseException, not 
>
> You could as well argue that "except" not doing type checking is simply
> a Python 2 bug, and the code in it will never be run anyways.
>
> Florian
>


___
pytest-dev mailing list
pytest-dev@python.org
https://mail.python.org/mailman/listinfo/pytest-dev

Re: [pytest-dev] [3.1 feature] "assert not raise exception" helper: opinions about the name

[Ronny Pfannschmidt]

Hi all,


my own stance is still to give it a different name,

while experimenting i learned of the fun fact that None is a "valid
exception type"
for except clauses on at least python 2.7
however on python3 it is invalid and a type error,

since the usage patterns of python don't hold such a case,
i'd like to use a distinct building block for expressing it in order to
match the semantics of the language closer

- Ronny

On 04.04.2017 19:19, holger krekel wrote:
> On Tue, Apr 04, 2017 at 15:48 +, Bruno Oliveira wrote:
>> On Fri, Mar 31, 2017 at 8:24 AM Bruno Oliveira  wrote:
>>
>>> Hi all,
>>>
>>> On Fri, Mar 31, 2017 at 7:13 AM Vasily Kuznetsov 
>>> wrote:
>>>
>>> Hi Holger and Ronny,
>>>
>>> I see merit in both of your points. All those "is not None" checks in
>>> between other logic and the proposed "raises unless the argument is None"
>>> semantics of pytest.raises do increase complexity (I'm not qualified to
>>> predict whether or not this increase is significant in terms of further
>>> maintenance though) but at the same time "pytest.raises(None)" API is
>>> convenient in some cases. What if we do something like this:
>>>
>>> ...
>>>
>>> The "is not None" checks are gone from the main logic and both APIs are
>>> available. Or if we would rather not have more than one way to do it, we
>>> can drop "does_not_raise" but otherwise still keep it a separate context.
>>>
>>> Seems like if we can agree on the API, a not-complexity-increasing option
>>> of implementation is possible.
>>>
>>>
>>> Now for the specific case of pytest.raises(None), I believe we can strike
>>> a good balance between a nice user interface and minimal internal impact
>>> like Vasily proposes, unless Ronny or others feel that pytest.raises(None)
>>> is not a good interface for this functionality.
>>>
>> Guys, anything else to add here? I would like to move the implementation
>> forward, either in its current form or changing it to pytest.raises(None).
> i was and am fine with your suggestion!
>
> IMO compared to markers or fixtures ... "pytest.raises" is relatively 
> self-contained side-effect-free code so i don't think it's neccessary
> to get scared about maintanability too much in this case.
>
> cheers, holger
>
>> Ronny, after the discussion here are you still against using
>> ptyest.raises(None), given that we can implement it easily by Vasily's
>> suggested implementation?
>>
>> Cheers,
>> Bruno.


___
pytest-dev mailing list
pytest-dev@python.org
https://mail.python.org/mailman/listinfo/pytest-dev

Re: [pytest-dev] [3.1 feature] "assert not raise exception" helper: opinions about the name

[Ronny Pfannschmidt]

Hi Holger,

what we do here is to add support for "inverted behavior" to a function!

this is a direct increase in inner complexity that looks easy on the
outside, but is not all all simple on the inside

its changes like that that ensure maintenance pain in future,

in reference, just take a look at marks,

that get copied around between different classes on a inheritance tree
and are a major mess to fix because of the sheer amount of easy changes
that being them to where they are now

same goes for the mess with fixture declaration that double as object
caches braking
while trying to introduce multi-skoped fixtures.

I am increasingly hostile to "easy" things that have a larger cost in
inner complexity,
because we don't have full time employees to deal with the fallout.

And the needless increase in complexity directly devalues the time i
spend volunteering
(because fixing finer details gets so much harder when complexity increases)

And with a Kid on the way i'm no longer willing to take those kinds of
blows in personal time at least.

-- Ronny


On 30.03.2017 23:36, holger krekel wrote:
> On Thu, Mar 30, 2017 at 23:08 +0200, Ronny Pfannschmidt wrote:
>> I do because we make something a "magical god function" again, more of the 
>> rant tommorow.
> God functions or objects are usually ones that do many different things.
> Here, "pytest.raises" deals with the dependent code block's exception 
> raising behaviour -- allowing None (to signal: no exception expected) 
> does not change or much extend this functionality.
>
> holger
>
>
>
>
>> Gn8, Ronny
>>
>> Am 30. März 2017 23:03:45 MESZ schrieb Bruno Oliveira <nicodde...@gmail.com>:
>>> On Thu, Mar 30, 2017 at 4:32 PM holger krekel <hol...@merlinux.eu>
>>> wrote:
>>>
>>>> It's a bit odd to introduce a new helper just for this particular
>>> case.
>>>> After skimming https://github.com/pytest-dev/pytest/issues/1830
>>>> i'd prefer the mentioned pytest.raises(None) solution which lets
>>> through
>>>> all exceptions
>>>> of the dependent code block.  Adding an example to the pytest docs
>>> and
>>>> extending
>>>> the pytest.raises help string and implementation would be enough IMO.
>>>> By contrast, adding a new helper feels like unneccessary clutter of
>>>> the pytest.* namespace. The above would then be:
>>>>
>>>>  @pytest.mark.parametrize('inp, expectation', [
>>>>  (-1, ValueError),
>>>>  (3.5, TypeError),
>>>>  (5, None),
>>>>  (10, None)])
>>>>  def test_bar(inp, expectation):
>>>>  with pytest.raises(expectation):
>>>>  validate_positive_integer(inp)
>>>>
>>>> where the parametrization is shorter and if one does not know
>>>> what pytest.raises(None) means one could find it easily in the
>>>> doc string or the pytest docs.
>>>>
>>> I agree. Does anybody else still prefers the original proposal?
>>>
>>> Cheers,
>>> Bruno.


___
pytest-dev mailing list
pytest-dev@python.org
https://mail.python.org/mailman/listinfo/pytest-dev

Re: [pytest-dev] [3.1 feature] "assert not raise exception" helper: opinions about the name

[Ronny Pfannschmidt]

I do because we make something a "magical god function" again, more of the rant 
tommorow.

Gn8, Ronny

Am 30. März 2017 23:03:45 MESZ schrieb Bruno Oliveira :
>On Thu, Mar 30, 2017 at 4:32 PM holger krekel 
>wrote:
>
>> It's a bit odd to introduce a new helper just for this particular
>case.
>> After skimming https://github.com/pytest-dev/pytest/issues/1830
>> i'd prefer the mentioned pytest.raises(None) solution which lets
>through
>> all exceptions
>> of the dependent code block.  Adding an example to the pytest docs
>and
>> extending
>> the pytest.raises help string and implementation would be enough IMO.
>> By contrast, adding a new helper feels like unneccessary clutter of
>> the pytest.* namespace. The above would then be:
>>
>>  @pytest.mark.parametrize('inp, expectation', [
>>  (-1, ValueError),
>>  (3.5, TypeError),
>>  (5, None),
>>  (10, None)])
>>  def test_bar(inp, expectation):
>>  with pytest.raises(expectation):
>>  validate_positive_integer(inp)
>>
>> where the parametrization is shorter and if one does not know
>> what pytest.raises(None) means one could find it easily in the
>> doc string or the pytest docs.
>>
>
>I agree. Does anybody else still prefers the original proposal?
>
>Cheers,
>Bruno.
___
pytest-dev mailing list
pytest-dev@python.org
https://mail.python.org/mailman/listinfo/pytest-dev

Re: [pytest-dev] doc/docs.pytest.org now proper with https

[Ronny Pfannschmidt]

+1


On 29.03.2017 16:30, holger krekel wrote:
> Thanks to Florian Schulze who instantiated an nginx/letsencrypt
> proxy on the planet.pytest.org pytest now serves ssl directly
> (https://docs.pytest.org ) directly by proxying and reverse-proxying 
> to readthedocs.org.  But we need an email admin address -- i can
> create a "pytest-ad...@pytest.org" alias which forwards to a 
> couple of committers and we could also mention it in the
> contacts page. Makes sense?
> holger
>
> ___
> pytest-dev mailing list
> pytest-dev@python.org
> https://mail.python.org/mailman/listinfo/pytest-dev

___
pytest-dev mailing list
pytest-dev@python.org
https://mail.python.org/mailman/listinfo/pytest-dev

Re: [pytest-dev] [proposal] using towncrier for merge-friendly changelog management

[Ronny Pfannschmidt]

Hi Bruno

towncrier takes the new entries, renders them to a text and then inserts
them either at the start, or right after a special marker line

-- Ronny


On 21.03.2017 16:32, Bruno Oliveira wrote:
> Hey Ronny,
>
> Oh you are absolutely right.
>
> Do you know what happens with the old CHANGELOG entries btw? 
>
> Cheers,
>
> On Tue, Mar 21, 2017 at 12:29 PM Ronny Pfannschmidt
> <opensou...@ronnypfannschmidt.de
> <mailto:opensou...@ronnypfannschmidt.de>> wrote:
>
> Hi Bruno,
>
> due to its Nature its best suited for introducing right after 3.1
>
> after all the before bits are already in place
>
> -- Ronny
>
> On 21.03.2017 14:41, Bruno Oliveira wrote:
> > Hi Ronny,
> >
> > I definitely like the idea! I agree our current CHANGELOG
> maintenance
> > could use some improvement. :)
> >
>     > We could introduce it for `3.1`, what do you think?
> >
> > On Tue, Mar 21, 2017 at 5:54 AM Ronny Pfannschmidt
> > <opensou...@ronnypfannschmidt.de
> <mailto:opensou...@ronnypfannschmidt.de>
> > <mailto:opensou...@ronnypfannschmidt.de
> <mailto:opensou...@ronnypfannschmidt.de>>> wrote:
> >
> > Hi all,
> >
> > today i noticed how pip manages its change-logs in a pretty
> > interesting way,
> >
> > they manage the fragments to be composed before a release in
> the folder
> > "news" in files named like "$ticketnumber.$changetype"
> > before a release those files get take out and composed into the
> > change-log.
> >
> > The fabulous tool behind that is
> https://github.com/hawkowl/towncrier/ -
> > after taking a first look at it,
> > i believe it should be a massive enhancement compared to
> what we put
> > ourselves trough right now.
> >
> > i also would be delighted, if we used it in more projects ^^
> >
> > cheers,
> >
> > Ronny
> >
> >
> > ___
> > pytest-dev mailing list
> > pytest-dev@python.org <mailto:pytest-dev@python.org>
> <mailto:pytest-dev@python.org <mailto:pytest-dev@python.org>>
> > https://mail.python.org/mailman/listinfo/pytest-dev
> >
>

___
pytest-dev mailing list
pytest-dev@python.org
https://mail.python.org/mailman/listinfo/pytest-dev

[pytest-dev] [proposal] big flake8 cleanup before the 3.1 release

[Ronny Pfannschmidt]

Hi all,

before releasing 3.1 i would like to bring pytest up to coding standards
while not all agree on the exact rules of flake8,
i find it an insult to my eyes to that basically all tools that
don't/can't support all kinds of config files
pretty much show about half of pytest in violation all the time

what i certainly don't want to do, is start to disable code standard
enforcement on random projects,
so i want to enforce it - and that means fixing up pytest once and for all.

a good point in time would e to do it on the features branch right
before doing a release and merging back to master as it would create the
smallest merge effort.

additionally it would allow us to switch from travis for linting to a
dedicated service with better gh integration in future without
maintaining yet another massive exclude list

-- Ronny

___
pytest-dev mailing list
pytest-dev@python.org
https://mail.python.org/mailman/listinfo/pytest-dev

Re: [pytest-dev] [proposal] introducing attrs to the codebase

[Ronny Pfannschmidt]

Attrs dropped 2.6 pretty recently, it might be reasonably easy to add/keep
the support for the pip timeframe as well on the upstream,

i'll check wit the author

2016-12-06 12:15 GMT+01:00 Bruno Oliveira <nicodde...@gmail.com>:

> Oh good point Raphael.
>
> Here's the link for the discussion about pip dropping Python 2.6:
> https://github.com/pypa/pip/issues/3955
>
> Cheers,
> Bruno
>
> On Tue, Dec 6, 2016 at 8:57 AM Raphael Pierzina <raph...@hackebrot.de>
> wrote:
>
>> Hey there,
>>
>> I don’t mind adding a dependency as long as there is a need for it. +1
>>
>> The problem I see with ‘attrs’ as it stands today, is that it does not
>> support Python 2.6 whereas pytest does. So we probably want to get
>> https://github.com/pytest-dev/pytest/issues/1273 in before adding
>> ‘attrs’ as a dependency. I’m not up-to-date with how things are in pip as
>> to dropping Python 2.6 compatibility. I can’t seem to find a ticket on the
>> pip issue tracker.
>>
>> Best,
>> Raphael
>>
>> On 06 Dec 2016, at 09:52, Bruno Oliveira <nicodde...@gmail.com> wrote:
>>
>> Hi Ronny,
>>
>> Could you list the classes which you think would be changed to use
>> 'attrs'? I'm not against adding another dependency if it can help us
>> maintain the codebase. Also, introducing a new dependency should be done in
>> `3.1.0`, not in a patch release.
>>
>> Cheers,
>> Bruno.
>>
>> On Tue, Dec 6, 2016 at 5:44 AM Ronny Pfannschmidt <
>> opensou...@ronnypfannschmidt.de> wrote:
>>
>> Hi all,
>>
>> i'd like to introduce https://pypi.python.org/pypi/attrs as a
>> dependency,
>>
>> its a fairly usefull library that takes away quite some boilerplate and
>> common error cause while automatically adding repr, comparators and
>> similar small details to python classes.
>>
>> I have used it in a number of personal projects, and dont want to miss
>> it by now.
>>
>> -- Ronny
>> ___
>> pytest-dev mailing list
>> pytest-dev@python.org
>> https://mail.python.org/mailman/listinfo/pytest-dev
>>
>> ___
>> pytest-dev mailing list
>> pytest-dev@python.org
>> https://mail.python.org/mailman/listinfo/pytest-dev
>>
>>
>>
> ___
> pytest-dev mailing list
> pytest-dev@python.org
> https://mail.python.org/mailman/listinfo/pytest-dev
>
>


-- 

Red Hat GmbH, http://www.de.redhat.com/, Registered seat: Grasbrunn,
Commercial register: Amtsgericht Muenchen, HRB 153243,
Managing Directors: Charles Cachera, Michael Cunningham, Michael
O'Neill, Eric Shander
___
pytest-dev mailing list
pytest-dev@python.org
https://mail.python.org/mailman/listinfo/pytest-dev

Re: [pytest-dev] [proposal] introducing attrs to the codebase

[Ronny Pfannschmidt]

*resend after mistake*
Hi Bruno,

i was thinking of doing it in the features branch,

as far as i can tell it can be applied to all classes of the
code/traceback, report and node details as well of a lot of mark related
inner details

having low cost classes should also ease de-tangling node mark handling and
keywords

we still should investigate how to use it and if we should vendor it

-- Ronny

2016-12-06 10:52 GMT+01:00 Bruno Oliveira <nicodde...@gmail.com>:

> Hi Ronny,
>
> Could you list the classes which you think would be changed to use
> 'attrs'? I'm not against adding another dependency if it can help us
> maintain the codebase. Also, introducing a new dependency should be done in
> `3.1.0`, not in a patch release.
>
> Cheers,
> Bruno.
>
> On Tue, Dec 6, 2016 at 5:44 AM Ronny Pfannschmidt <
> opensou...@ronnypfannschmidt.de> wrote:
>
>> Hi all,
>>
>> i'd like to introduce https://pypi.python.org/pypi/attrs as a
>> dependency,
>>
>> its a fairly usefull library that takes away quite some boilerplate and
>> common error cause while automatically adding repr, comparators and
>> similar small details to python classes.
>>
>> I have used it in a number of personal projects, and dont want to miss
>> it by now.
>>
>> -- Ronny
>> ___
>> pytest-dev mailing list
>> pytest-dev@python.org
>> https://mail.python.org/mailman/listinfo/pytest-dev
>>
>
> ___
> pytest-dev mailing list
> pytest-dev@python.org
> https://mail.python.org/mailman/listinfo/pytest-dev
>
>
___
pytest-dev mailing list
pytest-dev@python.org
https://mail.python.org/mailman/listinfo/pytest-dev

[pytest-dev] [proposal] introducing attrs to the codebase

[Ronny Pfannschmidt]

Hi all,

i'd like to introduce https://pypi.python.org/pypi/attrs as a
dependency,

its a fairly usefull library that takes away quite some boilerplate and
common error cause while automatically adding repr, comparators and
similar small details to python classes.

I have used it in a number of personal projects, and dont want to miss
it by now.

-- Ronny
___
pytest-dev mailing list
pytest-dev@python.org
https://mail.python.org/mailman/listinfo/pytest-dev

Re: [pytest-dev] Commit access to pytest

[Ronny Pfannschmidt]

Hi All,

i believe that when we do something like this, we should lean in the
direction of C 4.1
and focus on enabling more people to merge good pull requests of others
(we already started to follow a informal process where we no longer
self-merge until approval)

With the review Approval system that came to github i feel that c4.1 it
not up to date for gh
(i.e. self merge after approval looks like a valid move now)

I like the idea of slowly iterating towards  a more open and inclusive
process.
Readily offering commit bits to people that Demonstrate
they can honor the Contribution Process is a beautiful first step.

-- Ronny

Am 14.11.2016 um 03:52 schrieb Floris Bruynooghe:
> Hi all,
>
> A while ago Ronny proposed to adopt the ZeroMQ C4.1 process.  While
> the discussion there never got very far (and I forgot to pick it up at
> the sprint) I'd like to propose a rather less radical workflow while
> attempting to make it easier for people to get on board.
>
> Basically I'd propose to give commit access to anyone who created a PR
> and followed it through to it being successfully merged (with
> changelog etc etc all done by the new contributor).
>
> The main reason to propose this is because right now we don't really
> have a clear policy on when someone joins the committers.  And it is
> much more inclusive to write down clear rules for this.  Gaining
> commit access is generally empowering and motivating and a good way to
> include new members in the development.
>
> What do other people think?
>
> Floris
> ___
> pytest-dev mailing list
> pytest-dev@python.org
> https://mail.python.org/mailman/listinfo/pytest-dev

___
pytest-dev mailing list
pytest-dev@python.org
https://mail.python.org/mailman/listinfo/pytest-dev

[pytest-dev] landing pytest.marked

[Ronny Pfannschmidt]

Hi everyone,

i'd like to bring https://github.com/pytest-dev/pytest/pull/1921 back to
attention

it fixes a long-standing issue wrt putting mark on parameter values while
properly separating the markers from the parameter value,

it has intentionally limited scope of only dealing with marks,
and provides a better solution to mark parameters, which also supports
functions as parameters.

the discussion on the pr itself has gone a bit too broad,
and i'd like to call back to the solution of a concrete scoped problem

perhaps marking the feature itself experimental

-- Ronny

-- 

Red Hat GmbH, http://www.de.redhat.com/, Registered seat: Grasbrunn,
Commercial register: Amtsgericht Muenchen, HRB 153243,
Managing Directors: Charles Cachera, Michael Cunningham, Michael
O'Neill, Eric Shander
___
pytest-dev mailing list
pytest-dev@python.org
https://mail.python.org/mailman/listinfo/pytest-dev

Re: [pytest-dev] Proposal: python namespacign for markings/marker objects

[Ronny Pfannschmidt]

On 20.10.2016 15:14, Bruno Oliveira wrote:
> Hey Ronny,
>
>
> On Thu, Oct 20, 2016 at 10:55 AM Ronny Pfannschmidt
> <opensou...@ronnypfannschmidt.de
> <mailto:opensou...@ronnypfannschmidt.de>> wrote:
>
>> b) Another suggestion from Ronny: running collection and getting
>> used marker names. I'm not entirely sure what this means exactly,
>> since the original proposal doesn't use "names" at all, only the
>> objects directly.
> in my proposal the "name" of a marker would be either the current
> string or a type
>
>
> I'm still not getting how that fits with the collection of *tests*...
> consider this module:
>
> # contents of test_foo.py
> from pytest_blocker import Blocker
>
> @Blocker(123)
> def test_foo():
> pass
>
fist that usage is wrong, a *mark* object in my proposal is neither
usable as decorator,
 nor aware of mark mechanism, it can literally be any object

a *mark* is orthogonal to the process of marking, mixing those 2
concepts just creates a huge mess

after collection you have the test items, those have all the markers,
from the markers of test items one can infer the markers used in the
collected tests
-- Ronny
> How does pytest know that the file "test_foo" uses "Blocker", and that
> "Blocker" is a marker? One possible solution would be to inspect the
> namespace and see if any of the objects are a pytest.Mark subclass.
> I'm not suggesting that, just trying to illustrate what I mean by my
> question.
>
> another important part of my proposal is, that i want to decouple
> from the namespace we put into pytest.mark,
> after all there is now a multitude of plugins that register
> certain markers, sometimes for *different* usages and incompatible
> signatures
>
>
> That's the "flat namespaces" part of the discussion, if I'm
> understanding your proposal correctly. :)
>  
>
>> IMHO the discussion by email at this point is a little hard to
>> digest and to track all points/replies/proposals. Perhaps we
>> should move this discussion to a different venue? I propose an
>> issue on GitHub because the main issue containing the proposal
>> can be updated as the discussion progresses, although I'm not
>> sure if it would be any easier to track the discussion itself.
>> Perhaps using the Wiki would also be possible?
>>
> i could make a wiki page
>
>
> I would like to see what others think first. People might be OK with
> the current format, or have other suggestions.
>
> Cheers
> Bruno.

___
pytest-dev mailing list
pytest-dev@python.org
https://mail.python.org/mailman/listinfo/pytest-dev

Re: [pytest-dev] Proposal: python namespacign for markings/marker objects

[Ronny Pfannschmidt]

HI Bruno


On 20.10.2016 14:20, Bruno Oliveira wrote:
> On Thu, Oct 20, 2016 at 7:12 AM Ronny Pfannschmidt
> <opensou...@ronnypfannschmidt.de
> <mailto:opensou...@ronnypfannschmidt.de>> wrote:
>
>
> On 20.10.2016 10:56, holger krekel wrote:
> > Hey Ronny,
> >
> > i
> >> while trying to turn various internal markers of a work project
> >> into public plugins, i noticed a very plain problems -
> different other
> >> plugins used the same generic marker name for different
> purposes/intents
> >>
> >> such a flat namespace really doesn't scale
> > The more plugins there are the more it causes potential clashes
> of marker and fixture names.  We've had some discussions at the
> sprint about it IIRC.  I suggest that whatever namespacing we come
> up with it should be a) backward-compatible b) work for both
> markers and fixtures.
> python packages are pretty perfect for name-spacing markers, and its
> backward compatible
>
>
> Perhaps we should clearly state the points of Ronny's proposal so we
> can have a more structured discussion. Also, I suggest we try to
> discuss the proposal using an example which we are all familiar with,
> like the "skipif" marker. This also lets us see how we could
> eventually replace the current marker's implementation in the core
> (hopefully improving them by making them easier to understand) while
> also maintaining backward compatibility.
>
> * Problem 1: Flat namespace for markers
>
> This seems to be the main point of Ronny's proposal, the fact that a
> flat namespace for markers doesn't scale, with the potential of
> different plugins using markers with the same name causing problems
> and confusion.
>
> Ronny's proposal: import and use "marker objects"
>
> from myplugin import SkipIf
>
> @pytest.mark(SkipIf(sys.platform != 'win32', reason='win32 only'))
> def test_foo():
> pass
>
> * Problem 2: How plugins use markers and handle their arguments
>
> Currently plugins using markers have to deal with the *args and
> **kwargs parameters themselves, which is often messy and done incorrectly.
>
> Currently:
>
> def pytest_collection_modifyitems(items):
> for item in items:
> m = item.getmarker('skipif')
> condition = m.args[0] if skip.args else m.kwargs['condition']
> ...
>
> If getmarker also supports a `type` as parameter, this becomes possible:
>
> def pytest_collection_modifyitems(items):
> for item in items:
> skipif = item.getmarker(SkipIf)
> m.condition  # naturally available as an attribute
> ...
>
> IMO the API `item.getmarker(x)` can be kept backward compatible by
> accepting either a mark "global name" or a marker `type`. More on how
> to declare/register markers below.
>
> Some questions:
>
> 1. How to declare those markers?
>
> a) One of Ronny's suggestion is a new entry point: not entirely clear
> to me how it would be done. I personally don't like this idea, entry
> points are used to declare *plugins* only, and plugins use other
> mechanisms to declare fixtures, markers, hooks, etc. I don't think we
> should overload this.
>


> b) Another suggestion from Ronny: running collection and getting used
> marker names. I'm not entirely sure what this means exactly, since the
> original proposal doesn't use "names" at all, only the objects directly.
in my proposal the "name" of a marker would be either the current string
or a type
>
> One mechanism for declaring markers that I believe we discussed in the
> sprint was to provide a new hook which could be used to declare new
> markers. The hook would return a dict of marker names and opaque
> types, which could then be accessed by plugins using the current
> `item.getmarker(name)` API. For example, using "skipif":
>
> class SkipIf:
> def __init__(self, condition, *, reason=None):
> pass
>
> The hook would look like this:
>
> def pytest_register_markers(config):
> return {'skipif': SkipIf}
>
> This is similar to what Floris mentioned:
>
> @pytest.marker
> def skipif(condition, *, reason=None):
> return SkipIf(condition, reason=reason)
>
> In both cases, `@pytest.mark.skipif` would instantiate a new `SkipIf`
> instance with the parameters given and make it available to items
> using the `item.getmarker(name)` API.
another important part of my proposal is, that i want to decouple from
the namespace we put into pytest.mark,
after all there is now a multitude of plugins that register certain
markers, sometimes for *different* us

Re: [pytest-dev] Proposal: python namespacign for markings/marker objects

[Ronny Pfannschmidt]

Hi Holger,


On 20.10.2016 10:56, holger krekel wrote:
> Hey Ronny,
>
> i'd like to get back to your original suggestion ...
>
> On Wed, Sep 07, 2016 at 11:38 +0200, Ronny Pfannschmidt wrote:
>> Hi all,
>>
>> while trying to turn various internal markers of a work project
>> into public plugins, i noticed a very plain problems - different other
>> plugins used the same generic marker name for different purposes/intents
>>
>> such a flat namespace really doesn't scale
> The more plugins there are the more it causes potential clashes of marker and 
> fixture names.  We've had some discussions at the sprint about it IIRC.  I 
> suggest that whatever namespacing we come up with it should be a) 
> backward-compatible b) work for both markers and fixtures.
python packages are pretty perfect for name-spacing markers, and its
backward compatible

as for fixture namespaces, if we base them in plain string names and
continue doing so,
i feel absolutely certain it will break in a messy way and it has
different referencing needs than markers

so making 2 different things use the same mechanism is a guarantee that
we end up in a broken mess :(

i'd much rather start a discussion about using different means even for
fixtures,
but thats for a different topic that i hope to start this weekend (and
it would solve  lot of massive headaches wrt getting rid of py.path.local)


>> as such i would like to propose having marker types and objects as
>> importable objects
>>
>>
>> for example
>>
>>
>>
>> import pytest
>> from pytest_bugzilla import Blocker
>>
>>
>> @pytest.mark(Blocker(123))
>> def test_fun():
>>   pass
>>
>> that way we can do both, reuse python name-spacing *and* use more
>> meaningful objects for markings
> a few questions:
>
> - How would you integrate this with interactive help such as "py.test 
> --markers"? 
i see 2 sensible paths
a) a new entry-point to make them discover-able
b) running collection and getting a set of the used marker names

>
> - how would you access the Blocker marker from a hook?  New API?
   basically a mark name is either a identifier or a type

getmarker(Blocker) ->mark collection of Blocker objects
   
   this api break is needed anyway because what we have now is
demonstrably broken and unusable
   in various situations, usage and parameters we get different kinds of
objects with different behaviors
   
>
> - how would you apply it at module or class level?
pytestmark = [ Blocker(123) ]


>
> holger
> ___
> pytest-dev mailing list
> pytest-dev@python.org
> https://mail.python.org/mailman/listinfo/pytest-dev
-- Ronny

___
pytest-dev mailing list
pytest-dev@python.org
https://mail.python.org/mailman/listinfo/pytest-dev

Re: [pytest-dev] Fwd: Re: Proposal: python namespacign for markings/marker objects

[Ronny Pfannschmidt]

On 20.10.2016 09:17, Florian Bruhin wrote:
> * Ronny Pfannschmidt <opensou...@ronnypfannschmidt.de> [2016-10-20 09:07:47 
> +0200]:
>>> Finally, and I only just remembered, Holger has some lingering code
>>> somewhere which does something like:
>>>
>>> @pytest.marker
>>> def blocker(n):
>>> return {'issue no': int(n)}  # or whatever object you want your marker 
>>> to be
>>>
>>> @pytest.mark.blocker(123)
>>> def test_fun():
>>> pass
>> fixtures and markers are not symmetric and i don't see a reason to make
>> them be
>> just for looking similar, currently they are *completely* different ,
>> and i think that bringing them closer to look more nice will make things
>> MUCH worse.
>> they are belonging to different categories of "things" with completely
>> different desired behaviours.
> Then don't think of them like fixtures - but markers are essentially
> *functions*. They have arguments and keyword arguments, and currently
> everything defining a marker with arguments has to do the
> parsing/validating by itself. Holger's proposal seemed to clean this
> up and make things a lot easier.

from my pov thats **completely** wrong ,
a marker is an *object carrying metadata*
currently we use a own mechanism to make them, and a own mechanism to
validate them
and we don't even pass them correctly to a test item (and neither can we
without intentionally breaking the current apis)

from my pov we are just creating useless code with error potential if we
don't just make them plain simple objects
holgers proposal creates a whole name-spacing and parsing layer for
virtually no added benefit over just having a class
and it carries a certain guarantee for later issues

literally every single time we did something like that it ended with
bugs that stayed in for 5+ years
because nobody could fix them in reasonable time without breaking the api

sometimes it even was completely impossible to fix


-- Ronny
> Florian
>
>
>
> ___
> pytest-dev mailing list
> pytest-dev@python.org
> https://mail.python.org/mailman/listinfo/pytest-dev

___
pytest-dev mailing list
pytest-dev@python.org
https://mail.python.org/mailman/listinfo/pytest-dev

[pytest-dev] Fwd: Re: ANN: pytest-external-blockers - prototype released

[Ronny Pfannschmidt]

forwarding as i send it with the wrong sender address



 Forwarded Message 
Subject:Re: [pytest-dev] ANN: pytest-external-blockers - prototype
released
Date:   Wed, 19 Oct 2016 17:27:42 +0200
From:   Ronny Pfannschmidt <i...@ronnypfannschmidt.de>
To: Floris Bruynooghe <f...@devork.be>, Ronny Pfannschmidt
<rpfan...@redhat.com>
CC: pytest-dev <pytest-dev@python.org>



On 19.10.2016 17:21, Floris Bruynooghe wrote:
> On 4 October 2016 at 18:18, Ronny Pfannschmidt <rpfan...@redhat.com> wrote:
>> Hi all,
>>
>> i'm happy to announce the release of pytest-external-blockers [0]
>> it was created in order to be able to semantically track for what reasons a
>> test was skipped
>>
>> a normal `pytest.skip` doesn't offer a semantic difference between "skipped
>> for a local reason" and "skipped for a external reason"
>>
>> so we choose to pick a new verb.
>> that way every dynamic "skip" that happens for a external reason (like
>> database down, known to be broken tests, unavailable network service) can be
>> identified.
>>
>> In future i want to extend this concept to xfail.
>>
>> I'm hoping for some harsh critique :)
> This plugin is essentially trying to extend the possible outcomes, but
> it needs to piggyback the skip exception for integration with the core
> test running logic?  It would be nice if you could subclass the
> exception from a more generic pytest.OutcomeException or so instead.
> Otherwise I think I don't dislike what the plugin itself does too much
> ;-)
that simply isn't/wasn't exposed at the time
also the py.test internals are completely riddled with implicit
expectations about outcomes,
so much that it is scary

i'd love to be able to spell things more granular in different manners
as well

-- Ronny

> Floris
> ___
> pytest-dev mailing list
> pytest-dev@python.org
> https://mail.python.org/mailman/listinfo/pytest-dev

___
pytest-dev mailing list
pytest-dev@python.org
https://mail.python.org/mailman/listinfo/pytest-dev

[pytest-dev] Fwd: Re: Proposal: python namespacign for markings/marker objects

[Ronny Pfannschmidt]

forwarding as i send it with the wrong sender address

 Forwarded Message 
Subject:Re: [pytest-dev] Proposal: python namespacign for
markings/marker objects
Date:   Wed, 19 Oct 2016 17:24:32 +0200
From:   Ronny Pfannschmidt <i...@ronnypfannschmidt.de>
To: Floris Bruynooghe <f...@devork.be>, pytest-dev <pytest-dev@python.org>



On 19.10.2016 17:01, Floris Bruynooghe wrote:
> On 7 September 2016 at 10:38, Ronny Pfannschmidt <rpfan...@redhat.com> wrote:
>> Hi all,
>>
>> while trying to turn various internal markers of a work project
>> into public plugins, i noticed a very plain problems - different other
>> plugins used the same generic marker name for different purposes/intents
>>
>> such a flat namespace really doesn't scale
>>
>> as such i would like to propose having marker types and objects as
>> importable objects
>>
>> for example
>>
>> import pytest
>> from pytest_bugzilla import Blocker
>>
>> @pytest.mark(Blocker(123))
>> def test_fun():
>>   pass
>>
>> that way we can do both, reuse python name-spacing *and* use more meaningful
>> objects for markings
> I'm rather lukewarm for this proposal to be honest.  We already have
> an API which allows creating of mark objects for later re-use:
>
> blocker = pytest.mark.bugzilla_blocker
>
> @blocker
> def test_fun():
> pass
>
> So instead of changing the way way pytest.mark behaves I think it
> might be more interesting to look at alternative ways of creating
> marker objects.  E.g. if you could do:
>
> # pytest_bugzilla.py
> class Blocker(pytest.MarkerObject):
> def __init__(self, n):
> pass
>
> # test_fun.py
> from pytest_bugzilla import Blocker
>
> @Blocker(123)
> def test_fun():
> pass

> Then you can still import your marker and you also get more strict
> namespacing since you created a unique object in your module.  But the
> benefit is that from the point of view of using markers not much has
> changed.  There's just a new way of creating markers.
>
> What do you reckon about such an approach?
The main reason why i introduced the separation between objects and
marking was to prevent a damn unreasonable mess.
The objects that are the metadata put onto a function/object should be
completely unaware of the py.test marking functionality,

this is basics of separation of concern and prevents spaghetti behavior
 (like MarkInfo vs Markdecorator leaking into item.keywords and creating
a fun painful mess)



>
> Finally, and I only just remembered, Holger has some lingering code
> somewhere which does something like:
>
> @pytest.marker
> def blocker(n):
> return {'issue no': int(n)}  # or whatever object you want your marker to 
> be
>
> @pytest.mark.blocker(123)
> def test_fun():
> pass
fixtures and markers are not symmetric and i don't see a reason to make
them be
just for looking similar, currently they are *completely* different ,
and i think that bringing them closer to look more nice will make things
MUCH worse.
they are belonging to different categories of "things" with completely
different desired behaviours.
> This uses symmetry with how we create fixtures, which is nice.  But it
> does not solve the namespacing issue, which to some extend also exists
> in fixtures.  Just brainstorming to add something namespace like to
> that would be:
>
> @pytest.marker(ns='bugzilla')
> def blocker(n):
> return int(n)
>
> @pytest.mark.bugzilla.blocker(123)
> def test_fun():
> pass
>
> I admit this does not re-use the python module namespaces, which is
> probably a downside.
>
i am strongly opposed to inventing a own name-spacing mechanism there,
it would be another mess like the marker transfer, or the yield tests
execute test code at collection time messes

-- Ronny
> Floris
> ___
> pytest-dev mailing list
> pytest-dev@python.org
> https://mail.python.org/mailman/listinfo/pytest-dev


___
pytest-dev mailing list
pytest-dev@python.org
https://mail.python.org/mailman/listinfo/pytest-dev

Re: [pytest-dev] creating pytest-boxed and removing boxed from xdist

[Ronny Pfannschmidt]

On 12.10.2016 02:16, oliver wrote:
> On Tue, Oct 11, 2016, 18:57 Bruno Oliveira  > wrote:
>
> On Tue, Oct 11, 2016 at 7:46 PM oliver
> >
> wrote:
>
> Is there any plan to port boxed and xdist plugins to Windows?
> What are the issues that have prevented implementation from
> happening (or happening sooner, if planned)?
>
>
> Hey,
>
> The boxed implementation depends on os.fork, which is not
> available on Windows. But except for --boxed, xdist works just
> fine on Windows.
>
> A common question is "Why not use a sub-process instead?" One of
> the reasons is that is not really simple to serialize and send the
> collected tests on a wire to a subprocess, so xdist uses fork to
> spawn a child sharing the same memory and control it from master
> in case it crashes.
>
>
> Thanks for info. Just trying to see if I could help with this... "send
> the collected tests...  to a subprocess" and "control [subprocess]
>  from master in case it crashes" are not that difficult on Windows, is
> there some deeper problem or other requirement that is headache?
its halfway implemented as slave-restart, the main problem is that the
current implementation grew into spaghetti,
since it implements state-machines in a totally non-formal way thus has
impossible to debug bugs
>
> I think I read someone mention that the "slave restart"
> functionality is considered a good enough replacement for boxed, 
>
>
> This covers recovery after a test crashes the suite, but AFAICT it
> doesn't support isolating a test from all the other tests so no
> sharing of memory space, or to test mutually exclusive import
> configurations etc, does it?
all that's needed for full isolation is to instruct each slave to run
and teardown exactly one test
in fact the isolation will be much better than what we currently have
(fork for runtestprotocol)

i just absolutely want to avoid having to implement that flow on top of
the current code-base

-- Ronny


> Oliver
>
> -- 
> Oliver

___
pytest-dev mailing list
pytest-dev@python.org
https://mail.python.org/mailman/listinfo/pytest-dev

[pytest-dev] creating pytest-boxed and removing boxed from xdist

[Ronny Pfannschmidt]

Hi everyone,

in order to enable refactoring xdist,
i took out the boxed code and started to put it into

https://github.com/pytest-dev/pytest-boxed

the plan is to make the next release of xdist dependent on it, then
phase it out as dependency later

-- Ronny

___
pytest-dev mailing list
pytest-dev@python.org
https://mail.python.org/mailman/listinfo/pytest-dev

[pytest-dev] ANN: pytest-external-blockers - prototype released

[Ronny Pfannschmidt]

Hi all,

i'm happy to announce the release of pytest-external-blockers [0]
it was created in order to be able to semantically track for what reasons a
test was skipped

a normal `pytest.skip` doesn't offer a semantic difference between "skipped
for a local reason" and "skipped for a external reason"

so we choose to pick a new verb.
that way every dynamic "skip" that happens for a external reason (like
database down, known to be broken tests, unavailable network service) can
be identified.

In future i want to extend this concept to xfail.

I'm hoping for some harsh critique :)


[0]  https://github.com/RonnyPfannschmidt/pytest-external-blockers
  https://pypi.python.org/pypi/pytest-external-blockers

-- Ronny
___
pytest-dev mailing list
pytest-dev@python.org
https://mail.python.org/mailman/listinfo/pytest-dev

Re: [pytest-dev] the sorry state of pylib tests and pylib

[Ronny Pfannschmidt]

Hi Holger,

over the course of the next few months i'd like to run the following
actions on pylib

1. de-vendor apipkg - the version last released has bugfixes and works
in bpython (low efford)
2. de-vendor iniconfig - that allows to get rid of the pylib dependency
more easily (i already did a release, low to medium effort)
3. remove the svn paths (they are broken and nobody is stepping up to
fix them)
im considering making a call for participation on that one (low to
medium effort)

-- Ronny

On 27.09.2016 18:21, holger krekel wrote:

> Hi Ronny, everyone,
>
> i had actually replied to this mail a few days ago but it got lost due to my 
> playing around with new mail setups and clients :/
>
> So here is my 2cent collection IIRC:
>
> - IMO py is in low-effort maintenance mode.  Removing anything is likely
>   to break things, increase maintenance effort -> not worth it.
>
> - pylib could in tox.ini for testing just depend on pytest<3.0 and be done 
> with it.  That's probably good enough for the next 1-2 years.
>
> - meanwhile pytest can rather aim to vendor/get rid of things like we did 
> with py.code.  A big thing probably here is py.path.local usage.  Maybe 
> writing a wrapper around pathlib with py.path.local API would be a good not 
> too cumbersome strategy because it doesn't touch much code.
>
> best,
> holger
>
>
>
> On Thu, Sep 22, 2016 at 14:15 +0200, Ronny Pfannschmidt wrote:
>> Hi everyone,
>>
>> while fixing up some pylib tests i noticed a set of massive issues
>>
>> a) all py.code related tests are completely broken on pytest 3.0
>>
>> b) the svn related tests are completely broken and outdated (can we kill
>> it?)
>>
>> c) depending on environment there are massive issues with pylib path
>> encodings
>>
>> as far as i can tell thats just scratching the surface
>>
>>
>> im not yet sure what to do about it, but some thing has to be done ^^
>>
>>
>> -- Ronny
>>
>>
>> ___
>> pytest-dev mailing list
>> pytest-dev@python.org
>> https://mail.python.org/mailman/listinfo/pytest-dev


___
pytest-dev mailing list
pytest-dev@python.org
https://mail.python.org/mailman/listinfo/pytest-dev

Re: [pytest-dev] the sorry state of pylib tests and pylib

[Ronny Pfannschmidt]

On 27.09.2016 16:25, Bruno Oliveira wrote:
>
>
> On Tue, Sep 27, 2016 at 11:14 AM Ronny Pfannschmidt
> <opensou...@ronnypfannschmidt.de
> <mailto:opensou...@ronnypfannschmidt.de>> wrote:
>
>
>
> On 27.09.2016 15:59, Bruno Oliveira wrote:
>> On Tue, Sep 27, 2016 at 10:07 AM Ronny Pfannschmidt
>> <opensou...@ronnypfannschmidt.de
>> <mailto:opensou...@ronnypfannschmidt.de>> wrote:
>>
>> as things stand we have to maintain it until py.test no
>> longer depends on it
>>
>> a 2.0 release that kills py.code is a non-option as any
>> project dependign on ot will be limited in py.test version
>>
>>
>> Don't we already vendor py.code in pytest? That makes it
>> independent from what's installed on the system, at least as far
>> as py.code is concerned. My idea was just to remove parts which
>> py.test does not use or is vendored in (svn and py.code come to
>> mind).
>>  
> we vendored it to since changing its api in pylib would break
> down-streams
> if we now remove it we break down-streams just the same
>
>
> Yes, but those downstream projects would have the option o pinning to
> pylib < 2. Plus I think there must be almost no projects using it, it
> seems very pytest specific, that was one of the reasonings we used to
> justify vendoring py.code into pytest in the first place.
>
> and we could just have put it into a separate package to begin with
>
>
> One of the reasons to vendor it was to make it easier to fix bugs on
> it without having to apply the fix in a separate library and make a
> separate release; just moving py.code to a separate package would not
> help with that. 
>
well, the fact that we need more than 5 minutes to do a release is
concerning - i#d prefer if we could handle that differently
but well, vendoring py.code  destroyed most tests for py.code in pylib,
and we cant yet abandon pylib

by now i think it would be much more easy to separate py.code and and
prepare to either freeze or evolve it
>
>> my plan is to de-vendor bits of pylib (like iniconfig, apipkg)
>>
>> You mean remove them from pylib and publish them as isolated
>> packages? 
>>
> correct, the main reason to pull in things like iniconfig and
> apipkg was, bad packaging tooling 6-7 years ago
> its much better now
>
>
> I see, but that would break downstream projects which use those
> sub-packages as well, right? Note that I'm fine to do that in a 2.0
> release.
pylib can just expose them the same way it exposes py.test,
the main problem is stable api
>  
>
>> About py.path, we could implement a backward compatible interface
>> which is implemented as a thin layer in terms of pathlib (I think
>> we discussed this on GTalk some other day).
> thats one of the plans
> but i would like to eventually get rid of the api alltogether,
> we couldnt push it when we had the chance, and now pathlib is the
> standard
>
>
> Sure, but removing that API is a very long term plan IMHO because tons
> of code depend on it (tmpdir is certainly a very popular fixture) so I
> wouldn't dare remove it in the next few years. 
>
> We could eventually introduce a separate fixture which provides the
> pathlib interface, and eventually move tmpdir to a separate plugin for
> legacy code to use. But this would be very down the road in my opinion.
>
> Cheers,
> Bruno.

___
pytest-dev mailing list
pytest-dev@python.org
https://mail.python.org/mailman/listinfo/pytest-dev

Re: [pytest-dev] the sorry state of pylib tests and pylib

[Ronny Pfannschmidt]

HI Bruno,

as things stand we have to maintain it until py.test no longer depends on it

a 2.0 release that kills py.code is a non-option as any project
dependign on ot will be limited in py.test version

my plan is to de-vendor bits of pylib (like iniconfig, apipkg)

some have been lone projects at the beginning anyway (apipkg and
iniconfig got only vendored due to the bad state of packaging

stuff like svn can be removed as it is completely broken

basically once we de-vendored the bits we use and removed the py.path
dependency of pytest,
we can put pylib into a abandoned state

but before that *eek*

-- Ronny



On 27.09.2016 14:51, Bruno Oliveira wrote:
> Hi Ronny,
>
> How long do we plan to maintain pylib? Perhaps we can get rid of stuff
> we no longer wish to maintain (svn, py.code) and release a 2.0
> version? If someone still needs that functionality, they can pin it.
>
> Not sure about the py.path encoding errors you mention though.
>
> Cheers,
>
> On Thu, Sep 22, 2016 at 9:16 AM Ronny Pfannschmidt
> <opensou...@ronnypfannschmidt.de
> <mailto:opensou...@ronnypfannschmidt.de>> wrote:
>
> Hi everyone,
>
> while fixing up some pylib tests i noticed a set of massive issues
>
> a) all py.code related tests are completely broken on pytest 3.0
>
> b) the svn related tests are completely broken and outdated (can
> we kill
> it?)
>
> c) depending on environment there are massive issues with pylib path
> encodings
>
> as far as i can tell thats just scratching the surface
>
>
> im not yet sure what to do about it, but some thing has to be done ^^
>
>
> -- Ronny
>
>
> ___
> pytest-dev mailing list
> pytest-dev@python.org <mailto:pytest-dev@python.org>
> https://mail.python.org/mailman/listinfo/pytest-dev
>

___
pytest-dev mailing list
pytest-dev@python.org
https://mail.python.org/mailman/listinfo/pytest-dev

[pytest-dev] the sorry state of pylib tests and pylib

[Ronny Pfannschmidt]

Hi everyone,

while fixing up some pylib tests i noticed a set of massive issues

a) all py.code related tests are completely broken on pytest 3.0

b) the svn related tests are completely broken and outdated (can we kill
it?)

c) depending on environment there are massive issues with pylib path
encodings

as far as i can tell thats just scratching the surface


im not yet sure what to do about it, but some thing has to be done ^^


-- Ronny


___
pytest-dev mailing list
pytest-dev@python.org
https://mail.python.org/mailman/listinfo/pytest-dev

Re: [pytest-dev] pytest-warnings in 3.1

[Ronny Pfannschmidt]

Hi Florian,

thanks for the update.

im currently not too familiar with the internals myself

it seems like it will be slightly tricky to get right right,
as such i'd like to defer to 3.2 than end up in trouble right now

-- Ronny

On 22.09.2016 12:27, Florian Schulze wrote:
> Hi!
> I didn't/don't have time at the moment. But besides a minor issue
> there isn't anything to do on the plugin.
> In pytest itself we would have to replace the function calls with
> using the warnings module and gather those. We likely want to present
> pytest internal deprecations differently from in test warnings (the
> thing pytest-warnings does atm but doesn't separate).
> Regards,
> Florian Schulze
> On 22 Sep 2016, at 10:00, Ronny Pfannschmidt wrote:
>
> im not aware of anyone signing up for that
> as far as i remember there also was no further development on the
> plugin itself
>
>
> -- Ronny
>
>
> On 21.09.2016 18:46, Bruno Oliveira wrote:
>> Hi everyone,
>>
>> During the sprint Florian Schulze developed pytest-warnings[1],
>> and later we decided to merge that into pytest 3.1.
>>
>> I was trying to remember: did anybody volunteer to do that?
>>
>> Cheers,
>>
>> [1] https://github.com/fschulze/pytest-warnings
>>
>>
>> ___
>> pytest-dev mailing list
>> pytest-dev@python.org
>> https://mail.python.org/mailman/listinfo/pytest-dev
>
> ___
> pytest-dev mailing list
> pytest-dev@python.org
> https://mail.python.org/mailman/listinfo/pytest-dev 
>

___
pytest-dev mailing list
pytest-dev@python.org
https://mail.python.org/mailman/listinfo/pytest-dev

Re: [pytest-dev] tox is now on github

[Ronny Pfannschmidt]

Hi Oliver,

your pull request that was directly in the branch is already converted
to a branch on gh

for the 3 other ones, i am able to pull them and turn them into branches
however i wont be able to fix the references :/

i think i'd like to have a note from the authors if they prefer to do
the export on their own
or if they want to have a branch on GH to start off

cheers,
Ronny

On 18.09.2016 12:59, Oliver Bestwalter wrote:
> Hello Ronny,
>
> thanks a lot for going through the major PITA of doing such a move!
>
> One thing I noticed is that the 4 remaining pull requests have not
> been migrated. How can we deal with them?
>
> Also see: https://github.com/tox-dev/tox/issues/352#issuecomment-247791365
>
> The link to the pull request on Bitbucket now links to an unrelated
> issue on Github. Is that expected fallout from the move or would you
> have expected this to do the right thing on Github now?
>
> Cheers
> Oliver
>
> On Sat, 17 Sep 2016 at 22:14 Ronny Pfannschmidt
> <opensou...@ronnypfannschmidt.de
> <mailto:opensou...@ronnypfannschmidt.de>> wrote:
>
> Hello everyone,
>
> i am pleased to announce that after some setbacks
> we now have finished the repository and
> issue tracker migration for tox to github.
>
> its new home is https://github.com/tox-dev/tox
>
> due to the setbacks i ended up deferring various detail works
> (like travis/readthedocs)
> those will be finished during the next few days.
>
> even before the announcement the new place already started
> brimming with
> activity
>
>
> -- Ronny
>
> ___
> pytest-dev mailing list
> pytest-dev@python.org <mailto:pytest-dev@python.org>
> https://mail.python.org/mailman/listinfo/pytest-dev
>

___
pytest-dev mailing list
pytest-dev@python.org
https://mail.python.org/mailman/listinfo/pytest-dev

[pytest-dev] the move of pylib to github is technically finished

[Ronny Pfannschmidt]

Hi all,


i finished the move to github and did a few simple fixups
in the process i learned various details, and fixed bugs in the
migration tool

now i feel confident i can do the same for tox in the afternoon.

i'll finish up the detail works with pylib and create issues wrt its
updating to pytest 3.x

then i#ll focus on tox


-- Ronny

___
pytest-dev mailing list
pytest-dev@python.org
https://mail.python.org/mailman/listinfo/pytest-dev

Re: [pytest-dev] transfer repo / pypi access / ML announce

[Ronny Pfannschmidt]

random thought - i do wonder if we should just publish a rss feed with the
releases

2016-09-14 18:33 GMT+02:00 holger krekel :

> On Wed, Sep 14, 2016 at 15:48 +0200, Florian Bruhin wrote:
> > Hey,
> >
> > * holger krekel  [2016-09-14 13:58:18 +0200]:
> > > I am a bit concerned that people who transfer repos to pytest-dev
> > > think that it receives magic maintenance
> >
> > I read your sentence saying this does happen, and not that you're
> > concerned that it could happen, right?
> >
> > If so, what makes you think that?
>
> we had a discussion on this at the sprint IIRC.  The contributing text is
> not explicit about it.  but if it isn't a real problem that's great - i
> don't know to be honest.
>
> > > lastly, if we had a pure pytest-announce mailing list we could
> > > announce new pytest-dev plugins (from time to time) and releases
> > > there. We can certainly get that list on python.org.
> >
> > We already have testing-in-python, pytest-dev and python-announce, do
> > we really need a pytest-dev-announce too?
>
> FYI on testing-in-python someone pushed for not having pytest dev micro
> releases announced and bruno/me agreed on only announcing minor/major
> releases.
>
> pytest-announce would be restricted and only used for pytest related
> announcements whereas testing-in-python is a discussion list and
> python-announce sees tons of announcements unrelated to pytest.
>
> holger
> ___
> pytest-dev mailing list
> pytest-dev@python.org
> https://mail.python.org/mailman/listinfo/pytest-dev
>



-- 

Red Hat GmbH, http://www.de.redhat.com/, Registered seat: Grasbrunn,
Commercial register: Amtsgericht Muenchen, HRB 153243,
Managing Directors: Charles Cachera, Michael Cunningham, Michael
O'Neill, Eric Shander
___
pytest-dev mailing list
pytest-dev@python.org
https://mail.python.org/mailman/listinfo/pytest-dev

Re: [pytest-dev] transfer repo / pypi access / ML announce

[Ronny Pfannschmidt]

anything that can run deploy scripts works

-- Ronny

2016-09-14 16:12 GMT+02:00 Sebastian Rahlf <ba...@redtoad.de>:

> Little word of caution: Not all plugins are on github/use git.
> Travis will only work with github projects afaik.
>
> Sebastian
>
> 2016-09-14 14:01 GMT+02:00 Ronny Pfannschmidt <
> opensou...@ronnypfannschmidt.de>:
>
>> sounds good to me,
>>
>> can we up the release automation requirements,
>> so git tag + travis deploys can be used for releasing?
>> best, Ronny
>>
>>
>> On 14.09.2016 13:58, holger krekel wrote:
>>
>> I am a bit concerned that people who transfer repos to pytest-dev think that 
>> it receives magic maintenance because this relevant section in the docs
>> http://doc.pytest.org/en/latest/contributing.html#submitting-plugins-to-pytest-dev
>>
>> is not very explicit about it, even says "sharing some of the maintenance 
>> responsibility".  I suggest we explicitely say that maintainers are 
>> generally expected to continue maintaining their plugins.
>>
>> And how about having a "pytest-dev" user which has release rights on pypi 
>> for all pytest-dev plugins?  The credentials could be shared in a file in 
>> our public repo, encrypted to known GPG public keys. Speaking of which, we 
>> could collect gpg keys of contributors in another file.
>>
>> lastly, if we had a pure pytest-announce mailing list we could announce new 
>> pytest-dev plugins (from time to time) and releases there. We can certainly 
>> get that list on python.org.
>>
>> best,
>> holger
>>
>>
>>
>>
>> ___
>> pytest-dev mailing 
>> listpytest-dev@python.orghttps://mail.python.org/mailman/listinfo/pytest-dev
>>
>>
>>
>> ___
>> pytest-dev mailing list
>> pytest-dev@python.org
>> https://mail.python.org/mailman/listinfo/pytest-dev
>>
>>
>
> ___
> pytest-dev mailing list
> pytest-dev@python.org
> https://mail.python.org/mailman/listinfo/pytest-dev
>
>


-- 

Red Hat GmbH, http://www.de.redhat.com/, Registered seat: Grasbrunn,
Commercial register: Amtsgericht Muenchen, HRB 153243,
Managing Directors: Charles Cachera, Michael Cunningham, Michael
O'Neill, Eric Shander
___
pytest-dev mailing list
pytest-dev@python.org
https://mail.python.org/mailman/listinfo/pytest-dev

Re: [pytest-dev] transfer repo / pypi access / ML announce

[Ronny Pfannschmidt]

another point, we might want to introduce an pytest-attic org
and move unattended pytest-dev repos there based on primary
maintainership going away

-- Ronny


On 14.09.2016 13:58, holger krekel wrote:
> I am a bit concerned that people who transfer repos to pytest-dev think that 
> it receives magic maintenance because this relevant section in the docs 
>
> http://doc.pytest.org/en/latest/contributing.html#submitting-plugins-to-pytest-dev
>
> is not very explicit about it, even says "sharing some of the maintenance 
> responsibility".  I suggest we explicitely say that maintainers are generally 
> expected to continue maintaining their plugins.
>
> And how about having a "pytest-dev" user which has release rights on pypi for 
> all pytest-dev plugins?  The credentials could be shared in a file in our 
> public repo, encrypted to known GPG public keys. Speaking of which, we could 
> collect gpg keys of contributors in another file.
>
> lastly, if we had a pure pytest-announce mailing list we could announce new 
> pytest-dev plugins (from time to time) and releases there. We can certainly 
> get that list on python.org.
>
> best,
> holger
>
>
>
> ___
> pytest-dev mailing list
> pytest-dev@python.org
> https://mail.python.org/mailman/listinfo/pytest-dev

___
pytest-dev mailing list
pytest-dev@python.org
https://mail.python.org/mailman/listinfo/pytest-dev

Re: [pytest-dev] transfer repo / pypi access / ML announce

[Ronny Pfannschmidt]

sounds good to me,

can we up the release automation requirements,
so git tag + travis deploys can be used for releasing?

best, Ronny

On 14.09.2016 13:58, holger krekel wrote:
> I am a bit concerned that people who transfer repos to pytest-dev think that 
> it receives magic maintenance because this relevant section in the docs 
>
> http://doc.pytest.org/en/latest/contributing.html#submitting-plugins-to-pytest-dev
>
> is not very explicit about it, even says "sharing some of the maintenance 
> responsibility".  I suggest we explicitely say that maintainers are generally 
> expected to continue maintaining their plugins.
>
> And how about having a "pytest-dev" user which has release rights on pypi for 
> all pytest-dev plugins?  The credentials could be shared in a file in our 
> public repo, encrypted to known GPG public keys. Speaking of which, we could 
> collect gpg keys of contributors in another file.
>
> lastly, if we had a pure pytest-announce mailing list we could announce new 
> pytest-dev plugins (from time to time) and releases there. We can certainly 
> get that list on python.org.
>
> best,
> holger
>
>
>
> ___
> pytest-dev mailing list
> pytest-dev@python.org
> https://mail.python.org/mailman/listinfo/pytest-dev

___
pytest-dev mailing list
pytest-dev@python.org
https://mail.python.org/mailman/listinfo/pytest-dev

[pytest-dev] pylib conversation for review and bb ux mistake

[Ronny Pfannschmidt]

Hi all,

i prepared pylib for a move to github

the result can be reviewed under
https://github.com/RonnyPfannschmidt-migration-tests/pylib

while preping pylib for the move i declined a few simple pull requests
that where lacking some finishing touches

without realizing that on bitbucket, a decline is final :/

since its my fault i also volunteer for importing and finishing those.

-- Ronny


___
pytest-dev mailing list
pytest-dev@python.org
https://mail.python.org/mailman/listinfo/pytest-dev

Re: [pytest-dev] [wishlist] handling reuse of pytest plugins outside of pytest

[Ronny Pfannschmidt]

agin after accidential off-list:

A simple non code example would be using fixtures based on pytest-selenium
in a ipython session without running a test

2016-09-07 21:22 GMT+02:00 Bruno Oliveira <nicodde...@gmail.com>:

> Hey Ronny,
>
> Can you provide some examples of what you would like to accomplish? At
> least to me your email is a little vague and I wouldn't know where to start
> discussion about it...
>
> On Wed, Sep 7, 2016 at 10:47 AM Ronny Pfannschmidt <rpfan...@redhat.com>
> wrote:
>
>> Hi,
>>
>> recently i am starting to very painfully hit a massive wall
>> which is trying to use pytest integrated functionality outside of a test
>> run
>>
>> the inability to use them in some way is pretty much actively holding me
>> back
>> from running test helpers in ipython sessions & co
>>
>> at work we work around that by the means of having global instead of
>> using fixtures
>> and by re-implementing functionality and the using it both in fixtures
>> and in
>>
>> however we would like to get rid of that in some way
>>
>> but with the current constraints of being unable to use anything outside
>> of a test run we are pretty much forced to keep own implementations of
>> plugins like
>> pytest-baseurl. pytest-selenium, pytest-variables and more
>>
>>
>> -- Ronny
>>
>> --
>>
>> Red Hat GmbH, http://www.de.redhat.com/, Registered seat: Grasbrunn,
>> Commercial register: Amtsgericht Muenchen, HRB 153243,
>> Managing Directors: Charles Cachera, Michael Cunningham, Michael O'Neill, 
>> Eric Shander
>>
>> ___
>> pytest-dev mailing list
>> pytest-dev@python.org
>> https://mail.python.org/mailman/listinfo/pytest-dev
>>
>


-- 

Red Hat GmbH, http://www.de.redhat.com/, Registered seat: Grasbrunn,
Commercial register: Amtsgericht Muenchen, HRB 153243,
Managing Directors: Charles Cachera, Michael Cunningham, Michael
O'Neill, Eric Shander
___
pytest-dev mailing list
pytest-dev@python.org
https://mail.python.org/mailman/listinfo/pytest-dev

Re: [pytest-dev] [proposal] regendoc automation via travis + pytest-bot on GH

[Ronny Pfannschmidt]

Hi Bruno,

i hope i can make a initial take at the weekend,
i might need some support wrt api tokens/credentials

2016-09-07 17:03 GMT+02:00 Bruno Oliveira <nicodde...@gmail.com>:

> Hi Ronny,
>
> To me it sounds great if we could automate regendoc. As we discussed
> online, the approach you propose sounds good as well. Are you planning to
> tackle this anytime soon?
>
> Cheers,
> Bruno
>
> On Wed, Sep 7, 2016 at 8:33 AM Ronny Pfannschmidt <rpfan...@redhat.com>
> wrote:
>
>> hi,
>>
>> i would like to propose an regendoc automation using the pytest-bot
>>
>> the basic idea is, to have travis deploys on master/features that would
>> run regendoc, commit changes as pytest-bot, upload those to
>> pytest-bot/pytest-dev and open pull requests against pytest itself
>>
>> all we would need for that is a github api token fir pushes and creating
>> pull request objects
>>
>> the bot user would be both - a perfect place to put the intermediate
>> commits and as originator for the automated pull requests coming from travis
>>
>>
>> -- Ronny
>> --
>>
>> Red Hat GmbH, http://www.de.redhat.com/, Registered seat: Grasbrunn,
>> Commercial register: Amtsgericht Muenchen, HRB 153243,
>> Managing Directors: Charles Cachera, Michael Cunningham, Michael O'Neill, 
>> Eric Shander
>>
>> ___
>> pytest-dev mailing list
>> pytest-dev@python.org
>> https://mail.python.org/mailman/listinfo/pytest-dev
>>
>


-- 

Red Hat GmbH, http://www.de.redhat.com/, Registered seat: Grasbrunn,
Commercial register: Amtsgericht Muenchen, HRB 153243,
Managing Directors: Charles Cachera, Michael Cunningham, Michael
O'Neill, Eric Shander
___
pytest-dev mailing list
pytest-dev@python.org
https://mail.python.org/mailman/listinfo/pytest-dev

[pytest-dev] [wishlist] handling reuse of pytest plugins outside of pytest

[Ronny Pfannschmidt]

Hi,

recently i am starting to very painfully hit a massive wall
which is trying to use pytest integrated functionality outside of a test run

the inability to use them in some way is pretty much actively holding me
back
from running test helpers in ipython sessions & co

at work we work around that by the means of having global instead of using
fixtures
and by re-implementing functionality and the using it both in fixtures and
in

however we would like to get rid of that in some way

but with the current constraints of being unable to use anything outside of
a test run we are pretty much forced to keep own implementations of plugins
like
pytest-baseurl. pytest-selenium, pytest-variables and more


-- Ronny

-- 

Red Hat GmbH, http://www.de.redhat.com/, Registered seat: Grasbrunn,
Commercial register: Amtsgericht Muenchen, HRB 153243,
Managing Directors: Charles Cachera, Michael Cunningham, Michael
O'Neill, Eric Shander
___
pytest-dev mailing list
pytest-dev@python.org
https://mail.python.org/mailman/listinfo/pytest-dev

[pytest-dev] Proposal: python namespacign for markings/marker objects

[Ronny Pfannschmidt]

Hi all,

while trying to turn various internal markers of a work project
into public plugins, i noticed a very plain problems - different other
plugins used the same generic marker name for different purposes/intents

such a flat namespace really doesn't scale

as such i would like to propose having marker types and objects as
importable objects


for example



import pytest
from pytest_bugzilla import Blocker


@pytest.mark(Blocker(123))
def test_fun():
  pass

that way we can do both, reuse python name-spacing *and* use more
meaningful objects for markings

-- Ronny

-- 

Red Hat GmbH, http://www.de.redhat.com/, Registered seat: Grasbrunn,
Commercial register: Amtsgericht Muenchen, HRB 153243,
Managing Directors: Charles Cachera, Michael Cunningham, Michael
O'Neill, Eric Shander
___
pytest-dev mailing list
pytest-dev@python.org
https://mail.python.org/mailman/listinfo/pytest-dev

[pytest-dev] [proposal] regendoc automation via travis + pytest-bot on GH

[Ronny Pfannschmidt]

hi,

i would like to propose an regendoc automation using the pytest-bot

the basic idea is, to have travis deploys on master/features that would run
regendoc, commit changes as pytest-bot, upload those to
pytest-bot/pytest-dev and open pull requests against pytest itself

all we would need for that is a github api token fir pushes and creating
pull request objects

the bot user would be both - a perfect place to put the intermediate
commits and as originator for the automated pull requests coming from travis


-- Ronny
-- 

Red Hat GmbH, http://www.de.redhat.com/, Registered seat: Grasbrunn,
Commercial register: Amtsgericht Muenchen, HRB 153243,
Managing Directors: Charles Cachera, Michael Cunningham, Michael
O'Neill, Eric Shander
___
pytest-dev mailing list
pytest-dev@python.org
https://mail.python.org/mailman/listinfo/pytest-dev