pytest-dev
dropping the execmodel concept again
CC @ctheune @nicoddemus
the execmodel concept that @hpk42 introduced back in 2013 has multiple drawbacks
- it breaks execnet for testing qt, as the main thread is no longer under safe control
- it is completely incompatible with the async primitives that are starting to win (asyncio/trio/curio, async/await)
its not quite clear to me for what detailed use-case it was introduced, but as it is right now its a major show-stopper for me to introduce any support for modern async primitives
its the biggest reason why i dropped execnet maintenances, the second biggest reason being that there seemingly where possible placements (unfortunately the replacements turned out not to work out)
I think at this point we can just consider dropping anything that we don't want from execnet, given it has been in maintenance only mode, and not recommended for use in new projects, for years now.
However if we want to completely restructure execnet, we should create a new project (say execnet2), which has no backward compatibility guarantees at all (just bumping the major version to 2 is not enough as I doubt many users pin to <2).
@nicoddemus thats possibly a option as well, in that case i'd love to have a brainstorm with @ctheune about bootstrapping using wheel data + caches as well (i recall that it coudl be a partial game changer for https://batou.readthedocs.io/en/stable/ plus i want to get away from sending code snippets, and instead adding pure python wheels to sys.path as a starting point, maybe later on adopt something extra as well
also integration with tox via @gaborbernat might be interesting, so that the tox env on the remote will use the local wheel packages, and only the actual tests sync (this would be far superior to what pytest-cloud currently does wrt rsync of virtualenvs)
@RonnyPfannschmidt thanks for inviting me to the discussion and sorry for the silence. December was a complete NOOP month for me after the whole family cought covid ... :/
On the topic: I'd be happy to join the discussion and brain storm this. I can make time next week if you like.
@ctheune thanks for getting back
I hope everyone is well, it's just most unfortunate to get caught up with that
Im happy to make some time
Alright, I could do a 30 or 60 minute slot next week Monday (24th) or Friday (28th) around 9am-5pm Europe/Berlin. Does any time on those days fit for everyone else?
im currently fine with a slot somewhere between earliest start at 09:00 and latest end 12:00 on both days
depending on the number of participants 30 minutes may suffice,
Lets do Friday 28th 9:00. I blocked an hour in my calendar, but I'm also happy if we get it done in 30 minutes ;)
@ctheune exclent, any tool preference? else we cold just use the pytest discords voice/video channel
Happy to use either. We have a private Jitsi instance around as well. Let's try with Discord first and if that doesn't work we can fall back to Jitsi.
For everyone who wanted to attend besides @RonnyPfannschmidt and me: we have to reschedule as something personal popped up. We'll follow up here once things settle down.