# Should Flit become a PyPA project?

**URL:** <https://discuss.python.org/t/should-flit-become-a-pypa-project/11854>\
**Category:** Packaging\
**Created:** [November 10, 2021, 4:53pm UTC](https://discuss.python.org/t/should-flit-become-a-pypa-project/11854 "2021-11-10T16:53:23Z")\
**Posts on this page:** 1\
**Showing post:** 5

<div class="post-metadata">

**Author:** ![pf\_moore](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/pf_moore/32/35_2.png) [@pf\_moore](https://discuss.python.org/u/pf_moore)\
**Post date:** [November 10, 2021, 6:53pm UTC](https://discuss.python.org/t/should-flit-become-a-pypa-project/11854/5 "2021-11-10T18:53:57Z")

</div>

> [@takluyver](#):
>
> Should Flit move into PyPA maintenance?

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.

> [@takluyver](#):
>
> I wouldn’t abandon it if it became a PyPA project, but maybe it would mean I’m less of a bottleneck.

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).

> [@FFY00](#):
>
> I struggle to find enough reasoning to move `flit` into PyPA.

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.

---

_[View the full topic](https://discuss.python.org/t/should-flit-become-a-pypa-project/11854)._