[announce] Pybi and Posy

Yeah. And I’m still digesting it - but I agree with most of what you said.

And I can see why “yet another approach” is just making the problem worse. But what I like here is that it’s specifically trying to solve for the whole project lifecycle model that @njs linked to above (and I’ve referenced many times in the past). Most tools and approaches I’ve seen either frame themselves as “beginner friendly” (stage 1 and maybe 2), or as aimed at stage 3 (deployable webapp/reusable library/standalone app) and later. And both groups assume that stages 1 and 2 - “simple scripts” and “sharing with others” are beginner workflows, not needed by more advanced users[1]. Or at least, that’s how the documentation, examples and discussions feel to me.

I’ve no idea whether this project will succeed in unifying the full lifecycle described in that document. I don’t know if it’ll make our existing problems worse. I’m concerned about the fact that it’s inventing new mechanisms for things like isolation that may or may not work. I suspect that a model based around heavy manipulation of sys.path will cause huge problems for the static typing community, for example. But I’m pleased that someone is looking at a problem which I feel like struggled to express well enough to get the existing tools to pay attention to[2], and I’m glad that we’re still innovating, and not just fighting to consolidate what we have and deal with legacy issues.


  1. Look at scientific users struggling with “one venv per project” or “projects need to be built to be used” models to see what I mean. ↩︎

  2. Not that I want to try to claim to be some “lone voice in the wilderness” who’s the only one who sees the real issue here. ↩︎

4 Likes