Turn shutil into a runnable module

[zhihaoy]

Feature or enhancement

Proposal:

Introduction

py -m shutil copy2 ~/my/src.txt .

I often find it necessary to use some shutil functionalities in scripts. It does the right thing efficiently, has more precise error handling than cmake -E, and, most importantly, is cross-platform.

Precedent

The zipfile module can be used by py -m zipfile. It gains credits for being a cross-platform ZIP64 decompressor.

Details

• The subcommands should cover copyfile, copystat, copy, copy2, copytree, rmtree, move, chown, which, make_archive, and unpack_archive;
• The keyword arguments that are easy to represent in cmdline should be adapted into --kw arg cmdline options; flags can follow the style --follow_symlinks and --no-follow_symlinks.
• It would be even nicer if combined with a progress bar (See also: Add a basic progressbar implementation to shutil)

Links

DPO: https://discuss.python.org/t/turn-shutil-into-a-runnable-module/70503

Linked PRs

• gh-126562: Create package from shutil #130609

[ZeroIntensity]

I'm pretty sure this needs to get discussed on DPO.

[nineteendo]

Can't this be closed in the meantime?

[ZeroIntensity]

It could, but I don't see the need. It will just get reopened if we decide to go with the feature, and if not, then we'll close it.

[picnixz]

(Removing the pending label since we have now a discussion)

[ZeroIntensity]

Are we considering this approved?

[picnixz]

No, just that there is a discussion pending. In general, I consider pending when we have neither a discussion, nor a reply from the OP. Now, I'm just considering as being "under public consideration".

[ZeroIntensity]

FWIW, I think the DPO post was well received enough that submitting a PR isn't out of the question. Whether it gets merged is another thing, but the next logical step here is to actually implement it and see it in action.

[hugovk]

Hmm, although I don't see any support on DPO from a core team member, only one commented there with an alternative suggestion.

[ZeroIntensity]

Yeah, but TBF, core devs very rarely express interest in an idea there. The core team ultimately decides if it gets merged, anyway; DPO should be for gauging community interest.

[ZeroIntensity]

Now that a draft implementation is up, I'm bumping this to try and gather consensus, at least from Bénédikt and Hugo. In my eyes, the DPO thread went surprisingly well; it's relatively uncommon to get mostly-positive community feedback over there.

Personally, I think this could be an interesting feature, but it's also not hitting that "gut feeling" for the standard library. (I'm not sure how to describe that--e.g., argparse feels like the standard library, but click doesn't, yet I generally prefer the latter.)

If there are any triagers or core devs that have a strong preference here, speak now or forever hold your peace! I'll close this in the next few days if there's nobody willing to second the PR.

[hugovk]

My read of the DPO thread is that there was a bit of support, but most of the discussion was a digression around a general solution.

but it's also not hitting that "gut feeling" for the standard library.

Likewise. In general I am a fan of these type of CLIs, but this shutil one feels a bit of an arbitrary grab bag 🤷

[vstinner]

I concur with @hugovk and I suggest to close this issue as not planned.