Strategy for paver file (pavement.py)

[jaraco]

I'm deselecting pavement.py which is using paver module which seems is partially unusable on python 3.x because python cannot generate bytecode files of installed files because that module seems to be unmaintained and contains python 2.x syntax.

Does it make still sense to keep and use that file?

Originally posted by @kloczek in #2771 (comment)

[jaraco]

Currently, the pavement file provides the logic for updating the vendored dependencies. For my usage (running paver update_vendored), the behavior still works on Python 3.10rc1, even if some of the files in the pavement package are using an older syntax. I see also that paver does in fact depend on six, suggesting that the package was at some point updated to support Python 3, even if it might now be unmaintained.

So the short answer is that yes, the project still depends on that functionality, but it doesn't depend on it strongly. I'd be happy to accept a replacement, but I'd insist that replacement be readily cross-platform (excludes Make) and prefer it not require an additional language (prefer Python-based). Probably someone could readily port that logic to a tox env with a script in tools/.

I should note that ideally, the need for vendored dependencies will be removed entirely. In fact, #2764 proposes a change that removes the pavement.py file.

So the project isn't wed to Paver, but does require something to implement repeatable logic.