Join GitHub today
GitHub is home to over 40 million developers working together to host and review code, manage projects, and build software together.Sign up
Proposal: merge pytest-trio into the main Trio package #79
Installing compatible versions of pytest-trio and Trio itself is unreasonably difficult. pytest-trio often emits warnings on the latest version of Trio, but is broken on much older versions - though we don't specify a minimum version of Trio in the
Fortunately, there is a better way: we can simply distribute the pytest plugin as an integral part of Trio.
Doing some Git magic would even let us graft in all the history from this repo. Finally, we'd finish by making a last release of pytest-trio that marks the package as inactive, and does gives an import-time error if used with a post-merge version of Trio.
(Is pytest-trio spitting out any warnings currently that we need to fix?)
Trio itself is still in the adolescent stage where it's fairly aggressive about deprecating and changing things. This does make for churn across projects that use trio, and pytest-trio is certainly a project that uses trio :-). I don't know that it's any worse than other trio-based projects like trio-asyncio, trio-websockets, etc., though? pytest-trio doesn't use any internal APIs or anything. This is one reason why it would be really nice to have better release tooling, so we can more easily fix things up after Trio deprecates something... (python-trio/trio#220)
I've generally tried to be pretty mindful about splitting things up into sensibly scoped projects, on the theory that (a) the trio ecosystem is eventually going to be pretty big and diverse, so we might as well figure out how to do that right from the beginning, (b) my experience with big foundational projects like numpy or twisted is that it's very easy to end up with a lot of tenously-related stuff in your project that eventually turn into millstones around the necks of maintainers. A few years ago, the question here would be about merging
I'm not saying this is definitely a bad idea, just giving some background reasoning.
Yep, about CancelScope. I've just bundled that with #73, but of course CI won't pass until we release a new version of Trio! (maybe we could also adopt Hypothesis' release-every-PR tooling?)
Well, I've spent less time working on those, so...
More seriously, I'd personally integrate them too, at least once they're stable and going to be useful for the foreseeable future (so pytest-trio yes; hypothesis-trio no). For now, the alternative is to have the same maintainers working on all the projects, but with the added burden of cross-repo coordination!
My experience with Hypothesis is that bringing subprojects into a single parent package is a substantial net win, and that it's not that hard to deprecate things if we really need to - we're nowhere near the age or complexity of Twisted or Numpy yet, and I think we'll have a lot of warning before we get close.
I can see the argument against merging, but my experience with OSS monorepos has been good.
Maybe just automating the release process then?
That's also something we've done in Hypothesis, and per the article above it's amazing to work with. It doesn't need much code either; I wrote a travisCI one-liner to automatically release every commit on master with a new version number. Hypothesis uses some more scripts to avoid version collisions from concurrent PRs, but it's not that complicated
(for example: #73 is currently blocked waiting for a new release of Trio)
I'm in favor of merging because the time between a Trio release and the corresponding pytest-trio upgrade results in a lot of third-party failures.
Right now, many tests for
Trio could mitigate this by using a two-step deprecation model … but I consider that to be a workaround that can (and probably should) be avoided.