BUG: to_parquet write partitioned DataFrame to local filesystem for other filesystems (e.g. S3)

[kylase]

• I have checked that this issue has not already been reported.

• I have confirmed this bug exists on the latest version of pandas.

• (optional) I have confirmed this bug exists on the master branch of pandas.

---

Note: Please read this guide detailing how to provide the necessary information for us to reproduce your bug.

Code Sample, a copy-pastable example

import pandas as pd

remote = "s3://some-pandas-test-bucket/table"

pd.DataFrame([[1, 'a'], [1, 'b']], columns=['col_one', 'col_two']).to_parquet(remote, partition_cols=['col_two'])

Problem description

When a DataFrame is to be saved in object file system such as S3 as partitioned Parquet files, it saves the files in local file system instead, only a 0 byte object of is created, whereas the files are stored in the working directory as s3:

(pandas-dev) ➜  pandas git:(fix/parquet-write-dataset-s3) ✗ ls -R s3:
some-pandas-test-bucket

s3:/some-pandas-test-bucket:
table

s3:/some-pandas-test-bucket/table:
col_two=a col_two=b

s3:/some-pandas-test-bucket/table/col_two=a:
2a386111fd44400b8de1901254a7c485.parquet

s3:/some-pandas-test-bucket/table/col_two=b:
aefb0d5b907a415d943b6bcf59f2521d.parquet

On S3

(pandas-dev) ➜  pandas git:(fix/parquet-write-dataset-s3) ✗ aws s3 ls s3://some-pandas-test-bucket
2020-06-17 14:44:00          0 table

Expected Output

(pandas-dev) ➜  pandas git:(fix/parquet-write-dataset-s3) ✗ aws s3 ls s3://some-pandas-test-bucket --recursive --human-readable --summarize
2020-06-17 14:46:30    0 Bytes table
2020-06-17 14:46:30    1.3 KiB table/col_two=a/291b3f0d1d1f4eab9d6358e39ac47631.parquet
2020-06-17 14:46:30    1.3 KiB table/col_two=b/834e872441224885a5089554524d3b12.parquet

Output of pd.show_versions()

INSTALLED VERSIONS

commit : 5fdd6f5
python : 3.8.3.final.0
python-bits : 64
OS : Darwin
OS-release : 19.5.0
Version : Darwin Kernel Version 19.5.0: Tue May 26 20:41:44 PDT 2020; root:xnu-6153.121.2~2/RELEASE_X86_64
machine : x86_64
processor : i386
byteorder : little
LC_ALL : None
LANG : en_US.UTF-8
LOCALE : None.UTF-8

pandas : 1.1.0.dev0+1887.g5fdd6f50a.dirty
numpy : 1.18.5
pytz : 2020.1
dateutil : 2.8.1
pip : 20.1.1
setuptools : 47.3.1.post20200616
Cython : 0.29.20
pytest : 5.4.3
hypothesis : 5.16.1
sphinx : 3.1.1
blosc : None
feather : None
xlsxwriter : 1.2.9
lxml.etree : 4.5.1
html5lib : 1.0.1
pymysql : None
psycopg2 : None
jinja2 : 2.11.2
IPython : 7.15.0
pandas_datareader: None
bs4 : 4.9.1
bottleneck : 1.3.2
fastparquet : 0.4.0
gcsfs : None
matplotlib : 3.2.1
numexpr : 2.7.1
odfpy : None
openpyxl : 3.0.3
pandas_gbq : None
pyarrow : 0.17.1
pytables : None
pyxlsb : None
s3fs : 0.4.2
scipy : 1.4.1
sqlalchemy : 1.3.17
tables : 3.6.1
tabulate : 0.8.7
xarray : 0.15.1
xlrd : 1.2.0
xlwt : 1.3.0
numba : 0.48.0

[alimcmaster1]

Thanks @kylase - current implementation is that you have to pass a filesystem. Test for this here: https://github.com/pandas-dev/pandas/blob/master/pandas/tests/io/test_parquet.py#L546

Agree we should attempt to infer - might be best to wait until #34266 is in?

[jorisvandenbossche]

I think this should be solved now by #34266 ?

[kylase]

I think this should be solved now by #34266 ?
Yup, will close this.