This is an archive of the discontinued Mercurial Phabricator instance.

Differential D6258

packaging: coerce paths to strings
ClosedPublic

Authored by durin42 on Apr 16 2019, 5:55 PM.

Details

Reviewers
pulkit
Group Reviewers
hg-reviewers
Commits
rHG69b4426d288b: packaging: coerce paths to strings
Summary

Experimentally passing the pathlib.Path to zipfile.ZipFile fails on at
least some Python versions. I've gotten frustrated enough I'd rather
just force them to be strings and move on.

Diff Detail

Repository
rHG Mercurial
Lint
Automatic diff as part of commit; lint not applicable.
Unit
Automatic diff as part of commit; unit tests not applicable.

Event Timeline

durin42 created this revision.Apr 16 2019, 5:55 PM
pulkit accepted this revision.Apr 16 2019, 6:21 PM
Closed by commit rHG69b4426d288b: packaging: coerce paths to strings (authored by durin42). · Explain WhyApr 16 2019, 6:46 PM
This revision was automatically updated to reflect the committed changes.
durin42 added a comment.Apr 16 2019, 7:44 PM

Argh. This change appears to be wrong (!) so I'm going to drop it.

indygreg added a subscriber: indygreg.Apr 17 2019, 5:49 AM
In D6258#91055, @durin42 wrote:

Argh. This change appears to be wrong (!) so I'm going to drop it.

Eh? I don't see anything wrong with this. Casting a pathlib.Path to str should just work! In fact, it is necessary for older Python 3, as there was a long tail of stdlib functions that didn't accept pathlib.* when those types were first introduced. I believe 3.7 was the first release that fixed them all.

durin42 added a comment.Apr 17 2019, 2:44 PM
In D6258#91056, @indygreg wrote:
In D6258#91055, @durin42 wrote:

Argh. This change appears to be wrong (!) so I'm going to drop it.

Eh? I don't see anything wrong with this. Casting a pathlib.Path to str should just work! In fact, it is necessary for older Python 3, as there was a long tail of stdlib functions that didn't accept pathlib.* when those types were first introduced. I believe 3.7 was the first release that fixed them all.

At least one of the archive libraries can't cope with a destination being a Path but a source being a str, or something like that. zipfile can't (AFAICT) cope with Path objects on Python 3.5, but I worked around that by finding a Windows image at work that came with 3.7 already installed. :)

Revision Contents
Changeset List

Diff 14790

contrib/packaging/hgpackaging/util.py

import os import os
import pathlib import pathlib
import subprocess import subprocess
import tarfile import tarfile
import zipfile import zipfile
def extract_tar_to_directory(source: pathlib.Path, dest: pathlib.Path): def extract_tar_to_directory(source: pathlib.Path, dest: pathlib.Path):
with tarfile.open(source, 'r') as tf: with tarfile.open(str(source), 'r') as tf:
tf.extractall(dest) tf.extractall(dest)
def extract_zip_to_directory(source: pathlib.Path, dest: pathlib.Path): def extract_zip_to_directory(source: pathlib.Path, dest: pathlib.Path):
with zipfile.ZipFile(source, 'r') as zf: with zipfile.ZipFile(str(source), 'r') as zf:
zf.extractall(dest) zf.extractall(dest)
def find_vc_runtime_files(x64=False): def find_vc_runtime_files(x64=False):
"""Finds Visual C++ Runtime DLLs to include in distribution.""" """Finds Visual C++ Runtime DLLs to include in distribution."""
winsxs = pathlib.Path(os.environ['SYSTEMROOT']) / 'WinSxS' winsxs = pathlib.Path(os.environ['SYSTEMROOT']) / 'WinSxS'
prefix = 'amd64' if x64 else 'x86' prefix = 'amd64' if x64 else 'x86'