Remove pytest11 entrypoint and plugin, require tornado 6.1, remove asyncio patch, CI work#339
Conversation
tests/conftest.py
Outdated
| @@ -1 +1 @@ | |||
| pytest_plugins = ['pytest_jupyter_server'] No newline at end of file | |||
| pytest_plugins = ['jupyter_server.pytest_plugin'] | |||
There was a problem hiding this comment.
I guess I'm confused on when this is necessary. Given these tests will depend on pytest-jupyter's pytest_jupytercore and pytest_jupyterserver plugins, do consumers of those fixtures (including jupyter_server) require a pytest_plugins statement or is the extra-requires [test] dependency on pytest-jupyter sufficient?
In working with #335, it doesn't seem like this entry (referencing the now external plugins) makes any difference.
There was a problem hiding this comment.
If the pytest11 entry point in this repo is removed, there would be no particular way for pytest to know that it should use it, it wouldn't be imported, and the issue wouldn't occur for folk that have packages installed that try to actually .load their entrypoints.
Of the seven ways a plugin can be found, if it a test dependency doesn't use number 4, i'm a big fan of being explicit in conftest.py (number 7) or command line (number 1), but checked in as checked in inside a file that ends up in the distribution, e.g. pyproject.toml, or setup.cfg rather than rely on env vars, switches, etc.
do consumers of those fixtures (including jupyter_server) require a pytest_plugins statement
Once it's an explicit, real dependency, on a dedicated, test-time package, then everything is cool, and no pytest_plugin variable will be required, as number 4 will take care of it.
So generally: you'd never want anything referenced by Other People's Entry Points (what you might not control) to be behind an extra... depending on how they are used (e.g. have to be actually imported).
The whole prefix thing from #335? Yeah, well, that's just what a test regume is buying into with magic named functions. I'm not a huge fan, as the pattern (which, luckily, seems to be rather unique) doesn't play nice-nice with other tools (e.g. mypy, etc). But it's the only game in town, aside from the few little ecosystems where they felt they had to home-roll their own thing... noflo, robotframework, etc. have extremely unpythonic things they do, in the name of specific purposes.
| 'jinja2', | ||
| ], | ||
| extras_require = { | ||
| 'test': ['pytest-jupyter'], |
There was a problem hiding this comment.
not strictly required, but if the example is supposed to be illustrative...
| description = 'Jupyter Server Example', | ||
| long_description = open('README.md').read(), | ||
| python_requires = '>=3.5', | ||
| python_requires = '>=3.6', |
There was a problem hiding this comment.
I guess I'm not following the skull & crossbones commentary here, sorry about that. The change seems fine.
There was a problem hiding this comment.
Just meant 3.5 is EOL!
|
Thank you for your helpful responses and guidance on this Nick - it's much appreciated. I missed the examples test, as you're now discovering - sorry about that. Looks like it's just the One of the commits in #338 I was interested in was: 288d579. |
|
Re: 288d579 yeah, MANIFEST.in probably needs some gardening. It's yet another thing that doesn't really work the way anyone expects it would. The only way to be sure on this particular gotcha:
|
|
windows. ALWAYS WINDOWS. i think we have a winner here: smells like a |
|
Alright: codecov aside (didn't dig into what it was comparing against) this is ready for more serious review. Some of the changes to the test_file stuff could be reverted, but the parameterization is good for debuggability (e.g. what else would have broken, had the first thing tested not broken). |
kevin-bates
left a comment
There was a problem hiding this comment.
Thanks for the great work here Nick - it's much appreciated. I just had the few comments.
Regarding the empty tests/conftest.py file - is that necessary?
| # fallback to the pre-3.8 default of Selector | ||
| asyncio.set_event_loop_policy(WindowsSelectorEventLoopPolicy()) | ||
| """no longer needed with tornado 6.1""" | ||
| warnings.warn( |
There was a problem hiding this comment.
Should this remain behind a windows-3.8 check or be removed altogether? I understand its purpose, but now folks not on Windows-py3.8 systems will get this warning when it never applied to them in the first place.
There was a problem hiding this comment.
removed entirely... but while hidden behind a "private" member, I wouldn't rule out people having used it to avoid The Condition. Could just be removed immediately, but a release with a warning seems reasonable vs Your Stuff Breaks Now.
There was a problem hiding this comment.
Right on. I missed that the call server makes has been removed. This makes perfect sense - thanks.
|
|
||
| # include everything in package_data | ||
| include jupyter_server/**/* | ||
| recursive-include jupyter_server * |
| description = 'Jupyter Server Example', | ||
| long_description = open('README.md').read(), | ||
| python_requires = '>=3.5', | ||
| python_requires = '>=3.6', |
There was a problem hiding this comment.
I guess I'm not following the skull & crossbones commentary here, sorry about that. The change seems fine.
tests/test_files.py
Outdated
|
|
||
| async def fetch_expect_404(jp_fetch, *path_parts): | ||
| with pytest.raises(tornado.httpclient.HTTPClientError) as e: | ||
| r = await jp_fetch('files', *path_parts, method='GET') |
There was a problem hiding this comment.
This is a nice update - thank you.
Would you mind removing the unused variable?
|
Hate that codecov ❌ ... trying to fix on this PR seems out of scope, though 😢 Otherwise back to green, review issues about addressed, hopefully... |
jupyter_server/serverapp.py
Outdated
| assert tornado.version_info >= MIN_TORNADO | ||
| except (ImportError, AttributeError, AssertionError) as e: # pragma: no cover | ||
| raise ImportError( | ||
| _("The Jupyter Server requires tornado >=%s", ".".join(MIN_TORNADO)) |
There was a problem hiding this comment.
The version info isn't getting formatted into the string prior to its translation. Do the tuple elements also need to be strings for the join to work?
| # fallback to the pre-3.8 default of Selector | ||
| asyncio.set_event_loop_policy(WindowsSelectorEventLoopPolicy()) | ||
| """no longer needed with tornado 6.1""" | ||
| warnings.warn( |
There was a problem hiding this comment.
Right on. I missed that the call server makes has been removed. This makes perfect sense - thanks.
jupyter_server/serverapp.py
Outdated
| assert tornado.version_info >= MIN_TORNADO | ||
| except (ImportError, AttributeError, AssertionError) as e: # pragma: no cover | ||
| raise ImportError( | ||
| _("The Jupyter Server requires tornado >=%s.%s.%s", *MIN_TORNADO) |
There was a problem hiding this comment.
This still isn't handling things correctly. How about we just cut to the chase?
| _("The Jupyter Server requires tornado >=%s.%s.%s", *MIN_TORNADO) | |
| _(f"The Jupyter Server requires tornado >= {MIN_TORNADO[0]}.{MIN_TORNADO[1]}.{MIN_TORNADO[2]}") |
|
Sorry, haven't i18n'd in a while, am used to some other system, maybe
django, where you can pass the variable parts directly. Reading docs and
verifying locally, I see it should be...
_("yadda yadda %s.%.s.%s") % min_tornado
so that it doesn't have to be re-translated every time the number changes
|
Pin 1.0.x to tornado 6.1, remove asyncio patch [backport pieces of #339]
Uh oh!
There was an error while loading. Please reload this page.