Suggestion: Remove obsolete parquet from

The parquet package is unmaintained and outdated. It does not compile. It is confusing to new users who want to read and write parquet files.

Suggestion: Omit an error that parquet is deprecated and that an alternative like pyarrow.parquet should be used instead.

Sorry, what’s the parquet package? It doesn’t seem to be in the standard
library. If it’s a third-party package, what do you expect us to do
about it?

From what I can tell, the OP is likely referring to https://pypi.org/project/parquet/, which is indeed not part of stdlib. I would suggest having this thread moved over to https://discuss.python.org/c/packaging. I’m not overly knowledgeable with the packaging processes, I would imagine there’s a process for reporting a package as being obsolete.

Edit: I would also recommend adjusting the title to “Remove obsolete package ‘parquet’ from PyPI”.

1 Like

Also the first thing to do would be to contact the authors.

The process for asking for a project name to be reassigned is in PEP 541. But as people have advised here, and as is made clear in the PEP, the first step should always be to speak to the owner of the project.

Unless I’m misunderstanding the request of the author, it seems that they are only interested in flagging the project as deprecated and recommending an alternative package for users to use. Doing so should definitely involve contacting the authors first, but as far as I can tell, the process of publicly marking a project as deprecated/abandoned is not defined within PEP 541.

I think I was confusing this and another recent (similar) request.

There’s no means of marking a project as deprecated, largely because that would involve PyPI getting into the business of curating packages, which we don’t do. Sure, “this is unmaintained” seems like a relatively uncontroversial statement (assuming due process in establishing it) but once we start down that route, it very soon becomes a significant undertaking. There’s a lot of projects on PyPI that “obviously” aren’t for serious use and/or are unmaintained. For example, what about this project?

I’m not a PyPI maintainer/administrator, so I don’t speak for anyone but myself, but I don’t think it’s sustainable to start down the route of any sort of curation of projects on PyPI at this point. Maybe if we had a significant number of people offering to do the work…?

1 Like

That’s perhaps more a social task than one that needs a standardized process.

None the less, the ability for user side flagging of packages to PyPI admins, has an open issue on warehouse, as a feature request.