Should Flit become a PyPA project?

I’m very much in favour. I think it would be good to have multiple backends under the PyPA umbrella, precisely to avoid giving any impression that there’s a “PyPA preferred” option. And even if we ignore that, flit is definitely the sort of project I’d like to see under the PyPA banner.

Technically, “being part of PyPA” won’t make any difference here. You can ask for additional maintainers just as easily either way. There’s no requirement or implication that just by flit becoming a PyPA project, that all PyPA members will automatically be maintainers of flit (or that they’d necessarily want to be).

My view is the opposite - my default is that any packaging-related project that wants to be part of PyPA should be welcomed. We shouldn’t need to justify including projects, rather we should require justification from people who want to say “no” to a request to join.

2 Likes