Any plan to release 0.9.1 to PyPI?

[flcong]

0.9.1 has many additional features than 0.9.0, but it is not released to PyPi yet.

[GuidoBartoli]

Where is 0.9.1 mentioned? There are no releases on the official page here...

[flcong]

Yeah. I mean the current one. If I install using pip install git+https://github.com/astanin/python-tabulate.git@master, then pip list shows

tabulate                      0.9.1.dev29+g95ae5eb

[newville]

@astanin Yes, as with #329, it would be nice to see this project be updated. From the number of Issues and PR since the last release, it seems that there are many of us who would like to see this flourish, add features, and stay up to date. Is there any way we can help with that? Would a friendly fork be helpful?

[dave-doty]

I would also very much like the version 0.9.1 to be published to PyPi please.

[lingfish]

See also #281 .

[matkoniecz]

Would a friendly fork be helpful?

judging from project not being active enough to close #329 and last release being in 2022 - it seems that if anyone wants to see further development they should fork it and maintain the fork

(I was checking which library I should use, it looks like https://github.com/prettytable/prettytable is more alive and also does what I need)

[flcong]

Would a friendly fork be helpful?

judging from project not being active enough to close #329 and last release being in 2022 - it seems that if anyone wants to see further development they should fork it and maintain the fork

(I was checking which library I should use, it looks like https://github.com/prettytable/prettytable is more alive and also does what I need)

I also start to use pandas's built-in to_latex method from time to time... I'm not sure how PyPI works if someone forks this repo and make a new release to PyPI. I guess the new one does not share the same PyPI package name as this one, right? So have to rename the package to something like pytabulate instead of tabulate?

[matkoniecz]

I'm not sure how PyPI works if someone forks this repo and make a new release to PyPI. I guess the new one does not share the same PyPI package name as this one, right?

it is an entirely separate with own name

it would be an awful security risk if anyone would be able to replace any package by their own code

(though current owner could give access to some person they trust - though it also can easily go wrong)

[newville]

@matkoniecz I wrote to and heard back from @astanin in September (2024). I suggested moving the project to a GitHub origanization. Summarizing and paraphrasing his reply (to be clear, "all my words"):

a) he acknowledged that he was not actively using or giving much attention to this code.
b) he wanted this repo to remain a personal repo, but would not object to a more active friendly fork. He might even add a link to it here.

From my point-of-view:

A fork -- even friendly -- is not as good as moving the repo to a GitHub organization, which can have multiple maintainers. For one thing, a fork would not have the Issues or Pull Requests brought along; moving the repo would do this.

For a fork to be friendly, there has to be communication with the upstream or original developer(s). That seems uncertain.
It is not clear whether "push to PyPI" could ever be possible for a fork unless the original developer granted that -- and that is sort of an important part of this actual Issue, and it has simply been too long to trust any future engagement from the original author.

There are a few forks in existence and with one or two releases pushed to PyPI. I could be wrong, but these seem to be single-developers, and not actively maintained with the intention of support for public usage.

Theprettytable project looks nice but is not a drop-in replacement. It has a different API and a different feature set. That might be OK for a script or two, but it would be unfortunate to lose this code.

I would encourage a "detached and renamed" fork of this repo or even simply copying the project to one with a new name. I believe tabularize-ng has been proposed ('ng': next generation). I would also propose considering the names tabularizing and formatable.

I am over-extended with GitHub/Python projects and would be able to participate in development or maintenance of this project. If someone is willing to do maintenance and development and Issue/Pull Request triage, but would like help with an organization or getting started, I would be willing to help with that.

[matkoniecz]

It is not clear whether "push to PyPI" could ever be possible for a fork unless the original developer granted that

it is absolutely definitely impossible without cooperation from either original author or maybe pypi (and not sure is pypi allowing any takeovers like that)

it would be an awful security risk if anyone would be able to replace any package by their own code

BTW, ability to push to given pypi package name part is separate from control over the current Github repository

Theprettytable project looks nice but is not a drop-in replacement. It has a different API and a different feature set. That might be OK for a script or two, but it would be unfortunate to lose this code.

I am in a comfortable position of not using either, that is likely not a good solution for someone with existing involvement

I am over-extended with GitHub/Python projects

The same for me, I am not volunteering for it (especially as I found a viable replacement for myself)

[newville]

@matkoniecz

It is not clear whether "push to PyPI" could ever be possible for a fork unless the original developer granted that

it is absolutely definitely impossible without cooperation from either original author or maybe pypi (and not sure is pypi allowing any takeovers like that)
it would be an awful security risk if anyone would be able to replace any package by their own code
BTW, ability to push to given pypi package name part is separate from control over the current Github repository

To be clear, yes, I understand (and have experience with both) and agree with all of that. For someone else to push to the PyPI for tabulate, @astanin would have to grant that, from PyPI. I believe PyPI has sometimes allowed take-over of projects, say when a developer is documented to be unable to continue - not the case here. Unfortunately, PyPI also has a lot of packages with very little support or development that are effectively "name squatting," so finding a good name that is not already taken is challenging.

Again, my experience would lead me to conclude:

• a fork is needed, preferably to a GitHub organization, allowing multiple developers.
• a new name is needed.
• issues and pull requests will not be transferred unless or until @astanin wants that to happen.

For a fork to be "friendly", the original author has to be part of that friendly exchange. For this project, it could happen. But there are a lot of unacknowledged Issues and Pull Requests, and pleas from users to push a release. The developer @astanin has abandoned this project. He has convincingly demonstrated that they do not want to "be friendly" about forking, or transfer the project to an organization, or really show much respect to anyone who has tried to help develop this code.

Sorry if it sounds like I am disrespectful to anyone here. I do not mean to be. But I've seen this movie before. This project is abandoned by a developer who does not actually care about seeing it thrive, even if they tell themselves or others that they do. For the project to continue, a new maintainer is needed.

[matkoniecz]

And to be clear it is 100% fine for original author to abandon project, without handing it over. And I would be thankful that they did as much as they did and they were not obligated to do it either.

(does not apply to cases where they were obligated to do something and failed, but these cases are extremely rare if ever happening)