This has come up before, but it seems especially topical now. The pep517 package (which I maintain within PyPA) is built with Flit, as is @pradyunsg’s installer package, and build is considering switching to Flit. These are the low level tools which you can use to build & install everything else, so if build does make the switch, flit_core and tomli will be the first things you need if you want to build everything up from source (see Flit’s docs page on boostrapping).
I’m also conscious that I’m not fully keeping up with issues & pull requests on Flit. It’s pretty simple, which limits the changes it needs, and it’s up to date with things like PEP 621 and 660, but requests for things like namespace packages are stalled. I wouldn’t abandon it if it became a PyPA project, but maybe it would mean I’m less of a bottleneck.
If PyPA did adopt Flit, I’d like to avoid any suggestion that it’s the ‘official’ or ‘standard’ tool for creating & publishing packages. I don’t want what happened to pipenv. Poetry probably offers a better developer experience for many packages, setuptools can do many things that Flit can’t, and I expect that packages with complex build steps will use more powerful backends (e.g. this work for scipy). The only particular advantage of Flit is that it’s more or less the simplest possible packaging backend (for PEPs 518, 517, 621, 660…).
I think the main benefit of flit is that it has a much better bootstraping history than setuptools, and that would be the main motivator for me to accept it into PyPA, but at the end of the day I am not sure about it.
PyPA projects using it as the backend does not necessarily mean it should become a PyPA project. Speaking as a pypa/build maintainer, choosing flit as the backend is a purely circumstantial decision and I don’t think we are locked into it. One good example for how this can backfire is imagining we had moved toml into PyPA because it was a core component of the packaging ecosystem, even though we weren’t really tied to it, and then have everyone moving to tomli.
I struggle to find enough reasoning to move flit into PyPA. IMO it is just one of the currently popular build backends. I think its usage by PyPA projects is mainly a metric, not really reasoning itself.
I am not necessarily opposed to it, I just think we need to have a clearer and better reason.
I think flit does an excellent job of the task that it aims to do, has a fairly well defined scope (only pure Python projects with no additional build steps) and provides a fairly great user experience around it. I’d be more than happy to initiate a vote whenever we get to that stage.
One good reason would be to have at least one non-setuptools backend under the PyPA umbrella, to show that there are feasible alternatives to setuptools that provide a different (and IMO better) UX. We’d like to have non-setuptools alternatives (that was the whole point of PEP 517!) and having the popular ones under the PyPA umbrella sounds like a good plan as well.
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.
Add packaging to that list; we did it last year and then had to yank it out due to too many downstream distributors falling over from not supporting PEP 517 appropriately. I believe we gave those distributors a year to move so we should be able to make the move in 2022.
I’d also be in favor for the various reasons mentioned already: it’s really well-scoped, used as a dependency in a number of PyPA projects and used enough in the community to warrant worrying about solo-maintainance.
PyPA is the logical place since it has an accepted well-written governance model and is recognized via the PSF as a fiscally sponsored project (read: sustainability is possible). I can’t think of a better place at least.
Thanks everyone. It seems like most people are in favour, and if I read @FFY00’s post correctly, he’s not strongly opposed.
Looking at PEP 609, I understand that adding a project under the PyPA umbrella requires a vote on the pypa-committers mailing list. I’m already a PyPA member (for pep517), so I can propose it - will one of you (PyPA members) second it?
@mbussonn should also have a chance to object, as a co-maintainer of Flit, but I don’t imagine he will.
@FFY00: In fairness, it is hard to articulate exactly why I’d like Flit to be a PyPA project. I agree that it’s not necessary just because PyPA projects are using it, and I certainly hope no-one is locked into it. But the fact that several core packaging projects are using it or thinking of using it seems to indicate that it’s seen as a safe, reliable piece of packaging infrastructure. So it doesn’t seem inappropriate for it to be a PyPA project.
I know being a PyPA project doesn’t technically change who can collaborate on it. But perceptions matter, and I’d like to signal that Flit is maturing from purely ‘how Thomas wants to make packages’ into something a bit more community driven. I could make a new organisation on Github just for Flit, but if PyPA members are willing to accept it, I’d prefer that. I’d also like to offer merge rights to any PyPA members who are interested - although I’d ask people to make non-trivial changes through pull requests, as is common on most open source projects I’m familiar with.
I still mostly use flit whenever I can and haven’t contributed in a while (maybe I should change that).
I agree that I don’t want it to shadow something like poetry, though my impression is that flit is more targeted toward libraries, poetry to apps, and I have issues with poetry dev installs sometime.
Having recently been in situation were it was hard to access credentials, and even if I don’t think there is any change of current maintainer going rogue, I would be happy to see flit in a place where if anything happen more folks have access to credentials.
To that aim, would the move also require giving pypi credentials to more folks just in case ?
Thanks Paul, I’ll started a thread on pypa-committers.
Matthias, good point about PyPI credentials. I don’t think this move automatically means giving more people access to the project on PyPI, but I’m happy to do that at the same time. I’ve also been thinking of having a token on CI and releasing whenever a tag is pushed (I’ve been using this for pep517, and it’s pretty neat).
Yup, Flit is generally more focused on library development - it doesn’t manage any kind of lock file for you (which I consider an application thing).
As I mentioned before the vote, I’d like to offer maintainer access to Flit to anyone who’s already a PyPA committer. If you’re interested, get in touch with me. I’d ask everyone to work through pull requests and give people a chance to review & discuss changes before merging them. This is the norm for most open source projects I’m used to, and I’ll work this way as well.
(I also hope to make Flit more open & collaborative in general - using the list of PyPA committers is meant as a first step towards this, not a way to exclude everyone else.)
