pytest-dev
Remove dependency on py
We currently depend on the py project for its xml module as seen below:
gnikonorov:~/pytest-html$ git grep "from py\."
README.rst: from py.xml import html
README.rst: from py.xml import html
README.rst: from py.xml import html
pytest_html/plugin.py:from py.xml import html
pytest_html/plugin.py:from py.xml import raw
testing/test_pytest_html.py: from py.xml import html
testing/test_pytest_html.py: from py.xml import html
gnikonorov:~/pytest-html$ git grep "import py
Since this library is in maintenance only mode now, I think we should migrate away from it to other alternatives as it looks like we only use it to generate HTML elements for the report.
Thoughts @ssbarnea and @BeyondEvil ? If neither if you object I want to go ahead and see if I can migrate us off of it.
@ssbarnea I did some research on our options and the following seem to be popular:
- https://github.com/Knio/dominate
- https://github.com/leforestier/yattag
- Using vanilla python via already included libraries like xml.dom.minidom
Dominate seems to be the most popular open source one and could work for our needs. My only concern is if it ends up being abandoned at some point in the future that would defeat the purpose of migrating away from py. Personally, I think it looks easy to use but haven't actually tried using it yet.
I intentionally didn't consider templating engines, since I don't think they would be the particularly useful here.
What are your thoughts? We could always just keep the dependency on py, or roll our own if we wanted.
How strong is our need to process XML? Can't we just use jinja2 to produce html? Lets wait for extra feedback on this before even trying to implement anything, just to be sure we make a good long term decision.
As during the last year I had to work a little bit around javascript libraries, I realised how many good options are to produce HTML out of JSON, including with ANSI support. I wonder if it would not make sense to go towards the direction of making html report as thin as possible and let the processing happen in browser with javascript. This would enable a huge range of features that are impossible now like dynamic filtering, maybe even ability to combine multiple (json) reports under a single html page. Imagine that you can have 10 jobs producing json files, uploading them to a single folder and a html/js page that displays all of these, that page would not need to change when new reports are added.
I agree, let's wait on more feedback.
If @BeyondEvil is on board, this may even warrant its own project.
My thoughts:
- YES! This has been on my TODO for the longest, but realistically I won't get it done anytime soon. You'll be my Forever Hero @gnikonorov if you drive this over the finish line!
- Let's not move from one 3:rd party to another, let's keep it core python (see this comment for some good points).
- I'm 100% for keeping the library super thin and moving to client side calculation/rendering. A lot has happened since the inception of this plugin 5 years ago and I don't think any of the initial constraints are relevant anymore.
Also, like @ssbarnea says, going more towards JS will (probably, likely) make it a lot easier to fullfil users' feature requests etc.
Not sure we'll need a separate project, I think a V3 branch will be good enough. But I don't have a strong opinon either way.
Let's get this done! 👊
I propose porting all functionality to vanilla python first, then as a follow up seeing what we can move into javascript. How does everyone feel about that?
May I propose the opposite approach?
Let's say you have feature A.
Your suggestion: Port to vanilla python: cost 10 Port to JS: cost 10 Total cost: 20
My suggestion:
Scenario A (feature A is portable): Port to JS: cost 10 Total cost: 10
Scenario B (feature A is not portable): Port to vanilla python: cost 10 Total cost: 10
What I'm trying to illustrate is, why spend the time porting to vanilla python if we're going to port it to JS anyway?
Especially given that what we have today is working and even tho py.xml is in maintenance mode it's not deprecated or non-functioning.
Thoughts? @ssbarnea @gnikonorov
If a move to js is done, a investigation for consumption of the json lines style log seems mandatory
You mean this @RonnyPfannschmidt ?
Apologies for the perhaps ignorant question, but do you mean for storing report data or for logging or for something else entirely? 😊
If we're positive that we want to move to JS I agree.
I think we are? @ssbarnea ?
The only limiting factor on my own part is lack of (frontend) knowledge. But I'm positive we'll figure it out. 👍
Of course @BeyondEvil! I'll look into it this week. And communicate my findings here as I go along.
Hopefully I can have a feature branch up soon
@BeyondEvil sorry, i should have linked https://github.com/pytest-dev/pytest-reportlog
Ohh, that looks promising @RonnyPfannschmidt! 😃
Ok, so this is what's forming in my head, high level. This plugin will basically be a thin wrapper around the pytest plugins reportlog and metadata and also provide the hooks etc. for other plugins (like pytest-selenium). It will then dump all the data into a JSON file that the JS will read from. So basically that JSON file will contain the payload that traditionally is fetched with http-requests.
Does that make sense?
@BeyondEvil I think so and I like the idea.
So all HTML report generation will be done in JavaScript. we just keep the python for integration with pytest/other plugins
Exactly @gnikonorov !
I'll hit up some of my JS-peeps to see if they have any suggestions when it comes to JS-libs that can help us out.
There are some potential extras for this(like support for multiple logs, an actual long running webapp (imagine looponfail with a browser)
I like the ideas @RonnyPfannschmidt is proposing ( especially the long running webapp ).
Do we want to create a project for 'v2.0' enhancements we can implement once we achieve feature parity?
Do we want to create a project for 'v2.0' enhancements we can implement once we achieve feature parity?
Sounds good! 👍
Huh. For a second I think i had a stroke, yet-another-project but I soon realised it was just a github planning project, so yeah!