Please add a co-maintainer

[Spectre5]

@uiri, will you please consider adding @pradyunsg as a co-maintainer as he's offered multiple times in various issues. He's involved with the TOML language spec itself, the greater Python ecosystem, and appears to have more capacity than you currently do to work issues and pull requests. TOML V1.0 was released and it would be great to implement those updates into this project, e.g. mixed-type arrays.

[ofek]

@uiri Any update on this?

[eksortso]

Don't expect any updates until around Halloween. That seems to be the trend that @uiri follows.

This is unmaintainable. This package needs forked. And PyPI needs to track the new fork, since this one's just squatting on the toml name.

[johnthagen]

black, mypy (python/mypy#10824), and coverage have switched to tomli.

Some lengthy discussion about alternatives here:

• https://discuss.python.org/t/adopting-recommending-a-toml-parser/4068

[Spectre5]

I've also since switched to tomli.

[pradyunsg]

I've gone ahead and reached out to @uiri over a separate channel (email). Let's see if I get a response. If I don't, I'm planning on starting a PEP 541 request for maintainership transfer.

[ofek]

@pradyunsg Is that necessary since tomli is becoming more broadly adopted?

[pradyunsg]

Well, it would be good to have tomli's implementation ported over to this name TBH. Having the toml package on PyPI be the canonical and primary implementation that folks would want to use is a much better experience for TOML consumers -- something that I'm interested in. :)

[johnthagen]

Well, it would be good to have tomli's implementation ported over to this name TBH

It would also be nice if TOML support is ever upstreamed into the Python stdlib, to use the canonical toml name as well (and this project could be the canonical backport). @brettcannon has talked about this in the past. Being in the stdlib is also a pre-req for the flake8 developer to adopt pyproject.toml, etc.

[CAM-Gerlach]

It seems like the consensus on hukkin/tomli#141 was against it and I believe it is @pradyunsg 's plan to do so, but just to be clear, I'd aver that the package under the toml name would at least minimally want to support both reading and writing (at least essentially tomli + tomli_w). It is of course a hotly debated topic whether the stdlib package, whatever it is called, need support writing as well as reading for an initial implementation (to at least unblock packaging use cases), but if the toml name is to be co-opted, I'd think it should support at least the minimal, basic functionality of the existing packaging and what users and package authors would expect from a package under that name (given all the other such common format-named packages that I can recall, in the stdlib and otherwise, support both).

Anecdotal, but at least most, if not all of the number of packages I've authored/maintain that currently use toml need both the read and write support, so dropping half its core functionality would be a serious regression. (Lack of support for string/pathlib paths is another, given the significant convenience and simplicity benefit, breaking compatibility with wide existing practice and lack of a particular strong relationale for not doing so).

[pradyunsg]

If I don't, I'm planning on starting a PEP 541 request for maintainership transfer.

I did this, and @uiri has responsed on that issue stating that the project is not abandoned and they have not had the time to review my request for being added as a maintainer. :)

If it helps make this easier for him: here's a list of stuff I do -- https://pradyunsg.me/stuff/

[fgblomqvist]

@pradyunsg Did anything come of this? Or did @uiri just respond 2 months ago and then went dark again? Maybe it's possible to give the PEP 541 another shot in that case. Simply coming online to deny the PEP can't possibly count as being "reachable" or maintenance.

[pradyunsg]

Pretty much that, he came online, responded to the PEP 541 request and hasn’t said anything on any of these forums since.

[fgblomqvist]

@pradyunsg I'd say just raise the PEP again (wherever relevant). Busy or not, if someone can't make an hour worth of time in almost a whole year to just quickly evaluate if a person can qualify to be a co-maintainer it's just sad. They don't deserve to squat important package names just to keep their pride.

[CAM-Gerlach]

Pretty much that, he came online, responded to the PEP 541 request and hasn’t said anything on any of these forums since.

And in fact, the author seemingly wouldn't have even have done so, and the PEP 541 request been approved, had I not explicitly pinged them over on that issue (when they had not responded to numerous pings on the issue on their own project over the course of years). So you could say the current situation is at least partially my fault.

Busy or not, if someone can't make an hour worth of time in almost a whole year to just quickly evaluate if a person can qualify to be a co-maintainer it's just sad.

Particularly when, up until the author's long hiatus from the responsibilities of maintainership, said package was by far the most widely used Python library for parsing a format of major importance to the Python ecosystem, and the maintainer candidate is the maintainer of the very specification the library implements, one of the most important downstream consumers, and several other prominent Python projects.

While one is in no way required to assume the responsibilities of a maintainer, neither should one actively obstruct other worthy individuals from assuming the role, should suitable individuals step up to the plate (and I can't think of anyone more suitable than @pradyunsg ), and while one always strives to assume good faith, it is becoming increasingly difficult to do so given the continued pattern here.

[brettcannon]

With https://www.python.org/dev/peps/pep-0680/ accepted for Python 3.11, maintenance of the project will become less of a concern. Plus people can use tomli today if they want to align with what the stdlib is/will be using.

[uiri]

Added @pradyunsg as a collaborator on this repo.

@samvasko and @ryanhiebert are also in the list of co-maintainers, based on their prior contributions.

[pradyunsg]

Thanks @uiri! Would you also be willing to add folks to the project on pypi.org as owners/maintainers?

[CAM-Gerlach]

Thanks!

Thanks @uiri! Would you also be willing to add folks to the project on pypi.org as owners/maintainers?

Yeah, that's the big blocker—forking the project on GitHub was the previous plan anyway, but it was the PyPI access that was the subject of pypi/support#1557 .

[CAM-Gerlach]

To further reduce bus-factor, as a best practice it might also be better to migrate the repo to a GitHub org and adding a couple people (ideally 2-3 total) as owners, rather than having a major project tied to a single GitHub user's personal account (that can get deleted, hacked, etc).

[ryanhiebert]

I'm happy to help be an additional point of contact in this regard if appropriate and desired. I principally maintain a couple of other libraries, and while I don't expect to be directly fixing bugs or writing new code, I can occasionally assist in getting things unstuck for others, and I'm a maintainer on this repo.