What should I do if I want to make a library Brython-compatible?

[glyph]

This is a subset of #491 that is focused specifically on libraries that might want to run on both Brython and CPython without much difference in functionality; things for implementing data structures, file formats, etc.

Writing Python code in the manner that I am accustomed to—particularly to take advantage of the "same language as the backend" feature that Brython offers—would require using tons of libraries that are currently broken on Brython. To get those fixed we'll need to add continuous integration to tons of projects.

As an open-source library author, if I want to support a different runtime such as PyPy, I usually just drop a new environment into my tox.ini, then run my tests as I did previously, with the same runner.

However, the best practice for doing this on Brython is somewhat unclear - there have been a few interesting blog posts about testing an application using Selenium or whatever, but for libraries like automat https://github.com/glyph/automat/issues/124 that don't have any UI features but might just be useful utilities within the browser… what's the first step?

I tried to proof-of-concept this with a custom unittest runner via https://github.com/glyph/brytly/blob/0d7c313830e3fc1ddf71986dec1473df048b6ae4/brytly/phantestic.py / https://github.com/glyph/brytly/blob/0d7c313830e3fc1ddf71986dec1473df048b6ae4/brytly/phantestic.js but this was always a pretty brittle hack and was pretty invasive - it required using this specific test fixture class.

Getting something like pytest to work within brython I would imagine would be a major challenge in its own right, but even if we're going to stick just to stdlib unittest for the sake of compatibility it seems like forcing users to use an incomplete reimplementation for their base class is going to be a non-starter for most projects.

[PierreQuentel]

@glyph I'm not sure to understand; unittest is actually supported by Brython. I have developed an interface to run some of the tests in the CPython test suite (at /tests/unittests/index.html), with an adapted version of HTMLTestRunner. It's not super fast, but shows that a unittest-based test suite developed for a CPython application can be used unmodified in Brython.

[glyph]

Creating that index.html is quite a bit of additional work, and it looks like it won't catch new tests as they are added, which creates additional overhead - it looks they have to be manually added to the DOM?

But more importantly, how is index.html run to produce output on the console and test results to Travis? Most projects would want to see these type of build results when accepting a pull request.

[dunossauro]

I spent the week thinking about it.

I thought of creating dummies or mocks, to "emulate" Bryhton's behavior. So we could use the entire testing ecosystem. Like tox, pytest, mutation tests, coverage, linters.

But I cannot imagine the depth and time that would be invested in this creation. Besides the fact that mocks never really behave as they would look inside the browser. In that case we would still need something like selenium to make e2e.

[glyph]

There's also quite a bit of divergent behavior within the Brython runtime; for example, coroutines do not function according to spec, and there are big chunks of missing standard library functionality. Testing interactions with the DOM is a tiny fraction of what I'm worried about - I want to have test coverage that ensures things actually run within the browser context, not just that they're calling the right APIs…

[glyph]

(So a lot of the value of having a very basic test runner would be a to expose the set of divergent-from-CPython behaviors which are actually relied upon by existing libraries, rather than the ones that it seems like would be helpful to implement for fresh new code)

[glyph]

Maybe a basic start here would be something to run over a unittest test suite that would automatically emit the relevant index.html?

[ghost]

+1 on question. Hoping to get brython working with plotly.js