[RFC] Dropping python 2.7 support and other changes
BeyondEvil opened this issue · comments
I'm thinking it's time for a 2.0 release of the plugin.
Here's what I'm thinking we can do.
- Drop support for python 2.7
- Remove phantomjs as a driver
- Make all the cloud providers optional (same as
appium) - (Maybe make
requestsa "soft" requirement, see here for reasoning, not implementation)
Thoughts? Anything else we can do?
Thanks!
Maybe you have some input as well @Dude-x ? 😊
Sounds good. 👍
@BeyondEvil I wouldn't drop Python 2.7 support unless we are using an API that is in the later version of PyTest that doesn't support Python 2.7. Until there is an API change that forces us to update the minimum version, then we can drop Python 2.7 support.
Remove phantomjs as a driver
This seems reasonable since the project is dead.
Make all the cloud providers optional (same as appium)
Do you mean make it installable via the extras keyword? I would probably seek feedback from the community.
(Maybe make requests a "soft" requirement, see here for reasoning, not implementation)
This would make sense if we do separate the cloud providers. Even if we don't, we can make sure requests isn't imported if there is no need for it.
Thanks for your feedback @Dude-x, I appreciate it! 🙏
@BeyondEvil I wouldn't drop Python 2.7 support unless we are using an API that is in the later version of PyTest that doesn't support Python 2.7. Until there is an API change that forces us to update the minimum version, then we can drop Python 2.7 support. We've already done that in
pytest-html.
Right, as part of dropping python 2.7 support, I was thinking we up the minimum required pytest to a version that corresponds to that.
Make all the cloud providers optional (same as appium)
Do you mean make it installable via the extras keyword? I would probably seek feedback from the community.
Exactly, as it stands right now - you get all the providers installed, when it's unlikely you're using more than one. It might even be unusual that a majority of users uses even one of them - but I have no way of checking that afaik.
As for seeking feedback, any ideas of how to do that? Other than Slack?
@BeyondEvil I would request opinions from slack Python channel for SeleniumHQ, and introduce a breaking change on purpose to see who complains. Maybe if there are any mozilla folks around they can chime in. I have the impression that this project is not too popular.
Ugh... right in the feelz @Dude-x
I'm thinking it's time for a 2.0 release of the plugin.
Here's what I'm thinking we can do.
1. Drop support for python 2.7 2. Remove phantomjs as a driver 3. Make all the cloud providers optional (same as `appium`) 4. (Maybe make `requests` a "soft" requirement, see [here](https://github.com/pytest-dev/pytest-selenium/pull/228) for reasoning, not implementation)
These all sound good to me.
@BeyondEvil I would request opinions from slack Python channel for SeleniumHQ, and introduce a breaking change on purpose to see who complains. Maybe if there are any mozilla folks around they can chime in. I have the impression that this project is not too popular.
I don't think these changes will have an impact on any Mozilla users of the plugin. At least not any they couldn't recover reasonably easily from.
Would it be simpler to just split this up into multiple plugins, with each plugin using this one as a base?
This one could just provide the normal Selenium stuff, and others could add onto it. That way, if you want Appium for example, you could just install pytest-appium, which would have pytest-selenium as a dependency. No need for complex setup scripts or anything like that.
Would it be simpler to just split this up into multiple plugins, with each plugin using this one as a base?
Not a bad idea. But seems like a whole lot of overhead and maintenance. It would be 5 more repos/plugins to deal with. 😏
Would it though? This repo's last commit was 8 months ago. On top of that, I imagine most of the maintenance would only need to be done in the base pytest-selenium repo
Would it though? This repo's last commit was 8 months ago.
Well, that could be used as a counter-argument as well.
I would have to:
- Create 5 new repositories.
- Split out the tests for each of those 5, including any necessary boilerplate.
- Set up pypi for each.
- Set up Travis CI for each.
- Run the risk of (accidentally) introducing a breaking change in the "base" plugin, and because of tests now being split out, not finding out for a long time (due to low usage) resulting in when finding out - maybe have to introduce yet another breaking change - now for the users of the base plugin.
Then the extra maintenance cost of having to juggle 6 projects instead of 1. Even if low, like you mention below, it's still more projects meaning a higher cognitive load. And I'm not very smart to begin with. 🤣
All this for... what? What's the benefit? Apart from a little bit of separation of concerns, maybe? Seems like bad ROI to me. :)
On top of that, I imagine most of the maintenance would only need to be done in the base
pytest-seleniumrepo
You're probably correct. Partly because the code is pretty mature and not widely used.
You could use GitHub actions to have the other repos build when the base one is changed. Or you could have them all be in the same repo with a single test suite that just always checks all of them.
You could use GitHub actions to have the other repos build when the base one is changed.
Fair enough and another addition to the maintenance burden. 😊
Or you could have them all be in the same repo with a single test suite that just always checks all of them.
You mean like a monorepo?
Still, I don't see what we're gaining that is worth all that work?
For the few(?) that uses any of the cloud providers, the change that "faces" them would be going from
pip install pytest-selenium[saucelabs]
to
pip install pytest-saucelabs
Regardless, there's less work involved in first taking the suggested approach - and then if the need arises go the route of splitting them all out to individual repos.
I am not sure it's worth the effort of splitting to all the cloud providers. If cloud providers want to split things out to their own repos then fine and place the maintenance burden on them
We don't have to split repos but we can use entry points in setup.py to register the plugins but have them conditionally loaded.
Hi all! I'm jumping in here with two feet :)
I think a 2.0 release could be a good move. It could be a good way to get some more interest in this project?
Some other comments:
Drop support for python 2.7
Totally agree. I can do any grunt work or exploration needed for this.
Remove phantomjs as a driver
Also agree, and again I'm happy to do any work to make this happen.
Make all the cloud providers optional (same as appium)
This one is interesting. I can see it both ways, but similar to @AutomatedTester's opinion I can see some value in allowing each cloud provider to own some aspect of the plugin/project so they can maintain things as needed on their own. I'm definitely not in favour of breaking things up into multiple repos due to maintainability.
Thanks for your input @joshmgrant ! It's highly appreciated! 👊
I think it is better to drop Python 2.7 now since latest version of Pytest dropped Python 2.7.
Right now if I want to implement the change to make requests a lazy import, I would have to use deprecated import of from collections import MutableMapping instead of collections.abc which doesn't exist in Python 2.7.
By dropping 2.7, we would have to update our scripts to not run on PyPy either.
Do we have enough support to go with the original suggestions of @BeyondEvil for a 2.0 release? Looks like there's wide agreement for 1, 2, and 4 at least.
My plan for Selenium is to drop Py2 support after Selenium 4. If people want to use the new Bidi APIs in the python bindings will get an error asking them to upgrade to Py3 .
I think this library isn't as constrained as selenium on versions so if you move to supporting only py3 it will force people into doing it before I force them.
PR is started but should be viewed as WIP.
Regarding 3 (Make all the cloud providers optional (same as appium)), I think to do that, they need to be their own projects - which we concluded is not worth the work.