Still being maintained???

[ChrisBarker-NOAA]

It looks like there hasn't been any activity in here for a good while.

As far as I know, it's still working with modern Python, but there are some issues with build system and all that (see #125, for example).

If you want to maintain it, I (and probably others) can help with PRs, etc, but I'm not going to workon that unless someone says they's review and merge.

What shoudl be done (incomplete list):

• update build to pyproject.toml
• probably remove six and Py2 support
• test with python 3.9 -- 3.12 (3.13?)
• Add CI support -- a simple gitHub actions for the tests should ber pretty easy to set up.

Move to 1.0?

[Kludex]

I'm happy to review PRs... Please small ones so we can iterate faster.

[stankudrow]

I'm happy to review PRs... Please small ones so we can iterate faster.

Hello, let's review this PR (#126 ), shall we?

[Kludex]

What's this "shall we" about? 🤔

Smaller PRs will speed up reviews, and I can make more meaningful review as well.

[stankudrow]

What's this "shall we" about? 🤔

Smaller PRs will speed up reviews, and I can make more meaningful review as well.

It is about working together: you review, I respond and it goes on so until a PR is good enough to be merged.

[Kludex]

You seem to talk as if I have an obligation here.

Please break the PRs. It's more about the logical separation rather than the size. There's a change in how to build, the formatter, the CI...

On the package manager, I'd prefer to move to uv + hatchling as most of the ecosystem.

[stankudrow]

You seem to talk as if I have an obligation here.

Please break the PRs. It's more about the logical separation rather than the size. There's a change in how to build, the formatter, the CI...

On the package manager, I'd prefer to move to uv + hatchling as most of the ecosystem.

No problem + learn about 'uv' (will be the first attempt).

[Kludex]

Thanks. 🙏

You can get inspiration from https://github.com/Kludex/python-multipart/blob/master/pyproject.toml, if it helps.

[PythonCHB]

Note:

Formatting changes can make a mess of the history, so I’d suggest either:

1. don’t do it unless that section of the code is being touched for another reason.

or

2. put all the formatting updates in a single commit, with no other changes.

In either case, @Kludex can tell us what format style to prefer: black? Ruff? Just PEP 8, etc.

Also, could folks put here (or a new issue) what updates they are working on, so we don’t duplicate effort?

[stankudrow]

Note:

Formatting changes can make a mess of the history, so I’d suggest either:

1. don’t do it unless that section of the code is being touched for another reason.

or

2. put all the formatting updates in a single commit, with no other changes.

In either case, @Kludex can tell us what format style to prefer: black? Ruff? Just PEP 8, etc.

Also, could folks put here (or a new issue) what updates they are working on, so we don’t duplicate effort?

I can only guess, but it is probable to be ruff, which is not only a linter (replacing many of them), but also a formatter (and this can make black obsolete) + the wish for the uv as a project manager.

@PythonCHB , so you think it would be a bad step to present a PR with only linted code?

[ChrisBarker-NOAA]

you think it would be a bad step to present a PR with only linted code?

Sorry for the confusion -- no, that would be a good idea -- do all the re-formatting at once, commit that, and then do a PR of that, and only that. no other changes in that PR.

[Kludex]

Formatting changes can make a mess of the history, so I’d suggest either:

1. don’t do it unless that section of the code is being touched for another reason.

We can use the .git-blame-ignore-revs - I'm okay with it.

In either case, @Kludex can tell us what format style to prefer: black? Ruff? Just PEP 8, etc.

Following the python-multipart practices would be great.

[Kludex]

If possible, I'd like to start with having a pipeline, so we can speed up those changes as per #129 (comment).

[Kludex]

To answer the title: I'm here.