helmo/github-issues huggingface dataset:
Docs are not generated after latest release
State: closed | Author: albertvillanova (MEMBER)
Labels: name: maintenance

After the latest `datasets` release version 0.7.0, the docs were not generated.

As we have changed the release procedure (so that now we do not push directly to main branch), maybe we should also change the corresponding GitHub action:

https://github.com/huggingface/datasets/blob/edf1902f954c5568daadebcd8754bdad44b02a85/.github/workflows/build_documentation.yml#L3-L8

Related to:
- #5250

CC: @mishig25 

Comments: After a discussion with @mishig25:
- He said that this action should be triggered if we call our release branch according to the regex `v*-release`, as transformers does
- I said that our procedure is different: our release branch is *temporary* and it is deleted just after the release PR is merged to main
  - Indeed the release tag is not yet created when we make the release PR (not event when this is merged to main), but when we make the Release itself.

I was thinking that maybe we could change the triggering event: use `release` instead of `push`.

What do you think, @huggingface/datasets?

Why is it an issue if our branch is temporary ?

He says not; but the branch has no tag yet; does the doc building require the tag? Or just the version number in `__init__.py` or setup.py?

It uses `module.__version__` (i.e. the one defined in `__init__.py`) - no need to have a tag

https://github.com/huggingface/doc-builder/blob/81575cf081964c30ea5fd39450f4820db963f18e/src/doc_builder/commands/build.py#L69

Thanks, @lhoestq.

@mishig25 has manually forced the generation of the docs, that are live for 2.7.0 version: https://huggingface.co/docs/datasets/v2.7.0/en/index 

Cool ! this can be closed then ?

I was waiting for #5250 to be merged to close this.

just to confirm, is there anything I need to do from my side ? Or is everything good here ?
Protect the main branch from inadvertent direct pushes
State: closed | Author: albertvillanova (MEMBER)
Labels: name: maintenance

We have decided to implement a protection mechanism in this repository, so that nobody (not even administrators) can inadvertently push accidentally directly to the main branch.

See context here:
- d7c942228b8dcf4de64b00a3053dce59b335f618

To do:
- [x] Protect main branch
  - Settings > Branches > Branch protection rules > main > Edit
    - [x] Check: Do not allow bypassing the above settings 
      - The above settings will apply to administrators and custom roles with the "bypass branch protections" permission.
    - [x] Additionally, uncheck: Require approvals [under "Require a pull request before merging", which was already checked]
      - Before, we could exceptionally merge a non-approved PR, using Administrator bypass
      - Now that Administrator bypass is no longer possible, we would always need an approval to be able to merge; and pull request authors cannot approve their own pull requests. This could be an inconvenient in some exceptional circumstances when an urgent fix is needed
      - Nevertheless, although it is no longer enforced, it is strongly recommended to merge PRs only if they have at least one approval
- [x] #5250
  - So that direct pushes to main branch are no longer necessary

Comments: It seems all the tasks have been addressed, meaning this issue can be closed, no?
Complete doc migration
State: closed | Author: mishig25 (NONE)

Reverts huggingface/datasets#5214

Everything is handled on the doc-builder side now 😊

Comments: The docs for this PR live [here](https://moon-ci-docs.huggingface.co/docs/datasets/pr_5248). All of your documentation changes will be reflected on that endpoint.

Thanks for the fix @mishig25.

I guess this is the reason why the docs are not generated for the latest release version 2.7.0? https://huggingface.co/docs/datasets/index
Unable to rename columns in streaming dataset
State: closed | Author: peregilk (NONE)

### Describe the bug

Trying to rename column in a streaming datasets, destroys the features object.

### Steps to reproduce the bug

The following code illustrates the error:

```
from datasets import load_dataset
dataset = load_dataset('mc4', 'en', streaming=True, split='train')
dataset.info.features
# {'text': Value(dtype='string', id=None), 'timestamp': Value(dtype='string', id=None), 'url': Value(dtype='string', id=None)}
dataset = dataset.rename_column("text", "content")
dataset.info.features
# This returned object is now None!
```



### Expected behavior

This should just alter the renamed column.

### Environment info

datasets 2.6.1

Comments: Hi @peregilk this bug is directly related to https://github.com/huggingface/datasets/issues/3888, and still not fixed... But I'll try to have a look!

Thanks @alvarobartt. It is great if you are able to fix it, but when reading the explanation it seems like it is possible to work around it.

We also tried keeping the 'info.features' and then adding a modified version back after the remove/rename. Unforutunately that leads to a dataset that is not possible to iterate over.

So if you iterate over the `IterableDataset` as `next(iter(ds))` and then run `rename_columns` when checking that data it will work, but in the end, it's just renaming the column one example/batch at a time, not renaming the column name for all the entries in the dataset, which is the ideal.

@alvarobartt Thanks. My use case was that I wanted to do multiple things, ie removing all unnecessary columns, renaming some valid columns, and then using cast (in my case checking if the audio is not 16K and casting it). It is just convenient to look into the info.features between each of these operations. Alternatively, I will just plan ahead...;) To me it seems like all the operations are working.

Thanks for the advice. It was very useful.

If we know the features before renaming, then we know the features after renaming, so we can pass the new features to the returned dataset in `rename_column` indeed ! If anyone is interested in contributing, feel free to open a PR and I'd be happy to help / give some pointers :)

Sure @lhoestq thanks! I’ll try to work on that

#self-assign
Failed Data Processing upon upload with zip file full of images
State: open | Author: scrambled2 (NONE)

I went to autotrain and under image classification arrived where it was time to prepare my dataset. Screenshot below
![image](https://user-images.githubusercontent.com/82735473/201814099-3cc5ff8a-88dc-4f5f-8140-f19560641d83.png)


I chose the method 2 option. I have a csv file with two columns. ~23,000 files. 

I uploaded this and chose the image_relpath, and target columns. 

The image uploader said that I could only upload 10,000 singular images at a time so the 2nd option was to zip the images up and upload a zip archive which I did. 

That all uploaded. 

Now I have the message below. It appears the zip archive does just uncompress on the Hugging Face end? 
What am I missing here?



![image](https://user-images.githubusercontent.com/82735473/201813838-b50dbbbc-34e8-4d73-9c07-12f9e41c62eb.png)


Comments: cc @abhishekkrthakur @SBrandeis
Add num_proc to from_csv/generator/json/parquet/text
State: closed | Author: lhoestq (MEMBER)

Allow multiprocessing to from_* methods

Comments: The docs for this PR live [here](https://moon-ci-docs.huggingface.co/docs/datasets/pr_5239). All of your documentation changes will be reflected on that endpoint.

I ended up moving `num_proc` to `AbstractDatasetReader.__init__` :)

Let me know if it sounds good to you now
Make `Version` hashable
State: closed | Author: mariosasko (COLLABORATOR)

Add `__hash__` to the `Version` class to make it hashable (and remove the unneeded methods), as  `Version("0.0.0")` is the default value of `BuilderConfig.version` and the default fields of a dataclass need to be hashable in Python 3.11.

Fix https://github.com/huggingface/datasets/issues/5230

Comments: _The documentation is not available anymore as the PR was closed or merged._
Handle ArrowNotImplementedError caused by try_type being Image or Audio in cast
State: closed | Author: mariosasko (COLLABORATOR)

Handle the `ArrowNotImplementedError` thrown when `try_type` is `Image` or `Audio` and the input array cannot be converted to their storage formats.

Reproducer:
```python
from datasets import Dataset
from PIL import Image
import requests

ds = Dataset.from_dict({"image": [Image.open(requests.get("https://upload.wikimedia.org/wikipedia/commons/e/e9/Felis_silvestris_silvestris_small_gradual_decrease_of_quality.png", stream=True).raw)]})
ds.map(lambda x: {"image": True}) # ArrowNotImplementedError 
```

PS: This could also be fixed by raising `TypeError` in `{Image, Audio}.cast_storage` for unsupported types instead of passing the array to `array_cast.`

Comments: _The documentation is not available anymore as the PR was closed or merged._

> Not sure how we can have a test that is relevant for this though - feel free to add one if you have ideas

Yes, this was my reasoning for not adding a test. This change is pretty simple, so I think it's OK not to have a test for it.
Pin `typer` version in tests to <0.5 to fix Windows CI
State: closed | Author: polinaeterna (CONTRIBUTOR)

Otherwise `click` fails on Windows: 
```
Traceback (most recent call last):
  File "C:\hostedtoolcache\windows\Python\3.7.9\x64\lib\runpy.py", line 193, in _run_module_as_main
    "__main__", mod_spec)
  File "C:\hostedtoolcache\windows\Python\3.7.9\x64\lib\runpy.py", line 85, in _run_code
    exec(code, run_globals)
  File "C:\hostedtoolcache\windows\Python\3.7.9\x64\lib\site-packages\spacy\__main__.py", line 4, in <module>
    setup_cli()
  File "C:\hostedtoolcache\windows\Python\3.7.9\x64\lib\site-packages\spacy\cli\_util.py", line 71, in setup_cli
    command(prog_name=COMMAND)
  File "C:\hostedtoolcache\windows\Python\3.7.9\x64\lib\site-packages\click\core.py", line 829, in __call__
    return self.main(*args, **kwargs)
  File "C:\hostedtoolcache\windows\Python\3.7.9\x64\lib\site-packages\typer\core.py", line 785, in main
    **extra,
  File "C:\hostedtoolcache\windows\Python\3.7.9\x64\lib\site-packages\typer\core.py", line 190, in _main
    args = click.utils._expand_args(args)
AttributeError: module 'click.utils' has no attribute '_expand_args'
```

See https://github.com/tiangolo/typer/issues/427
fix: dataset path should be absolute
State: closed | Author: vigsterkr (CONTRIBUTOR)

cache_file_name depends on dataset's path.

A simple way where this could cause a problem:
```
import os
import datasets


def add_prefix(example):
    example["text"] = "Review: " + example["text"]
    return example


ds = datasets.load_from_disk("a/relative/path")
os.chdir("/tmp")

ds_1 = ds.map(add_prefix)
```

while it may feel that the `chdir` is quite constructed, there are many scenarios when the current working dir can/will change...

Comments: Good catch thanks ! Have you tried to use the absolue path in `MemoryMappedTable.__init__` in `table.py`?

I think it can fix issues with relative paths at more levels than just fixing it `load_from_disk`. If it works I think it would be a more robust fix to this issue

@lhoestq right, that actually fixed it indeed. I've pushed the changes (one-liner). lemme know if there's anything else you need for this fix

_The documentation is not available anymore as the PR was closed or merged._
Incompatible dill versions in datasets 2.6.1
State: closed | Author: vinaykakade (NONE)

### Describe the bug

datasets version 2.6.1 has a dependency on dill<0.3.6. This causes a conflict with dill>=0.3.6 used by multiprocess dependency in datasets 2.6.1

This issue is already fixed in https://github.com/huggingface/datasets/pull/5166/files, but not yet been released. Please release a new version of the datasets library to fix this.

### Steps to reproduce the bug

1. Create requirements.in with only dependency being datasets (or datasets[s3])
2. Run pip-compile
3. The output is as follows:

```
Could not find a version that matches dill<0.3.6,>=0.3.6 (from datasets[s3]==2.6.1->-r requirements.in (line 1))
Tried: 0.2, 0.2, 0.2.1, 0.2.1, 0.2.2, 0.2.2, 0.2.3, 0.2.3, 0.2.4, 0.2.4, 0.2.5, 0.2.5, 0.2.6, 0.2.7, 0.2.7.1, 0.2.8, 0.2.8.1, 0.2.8.2, 0.2.9, 0.3.0, 0.3.1, 0.3.1.1, 0.3.2, 0.3.3, 0.3.3, 0.3.4, 0.3.4, 0.3.5, 0.3.5, 0.3.5.1, 0.3.5.1, 0.3.6, 0.3.6
Skipped pre-versions: 0.1a1, 0.2a1, 0.2a1, 0.2b1, 0.2b1
There are incompatible versions in the resolved dependencies:
  dill<0.3.6 (from datasets[s3]==2.6.1->-r requirements.in (line 1))
  dill>=0.3.6 (from multiprocess==0.70.14->datasets[s3]==2.6.1->-r requirements.in (line 1))
```

### Expected behavior

pip-compile produces requirements.txt without any conflicts

### Environment info

datasets version 2.6.1

Comments: Thanks for reporting, @vinaykakade.

We are discussing about making a release early this week.

Please note that in the meantime, in your specific case (as we also pointed out here: https://github.com/huggingface/datasets/issues/5162#issuecomment-1291720293), you can circumvent the issue by pinning `multiprocess` to 0.70.13 version (instead of using latest 0.70.14).

Duplicate of:
- https://github.com/huggingface/datasets/issues/5162

You can also make `pip-compile` work by using the backtracking resolver (instead of the legacy one): https://pip-tools.readthedocs.io/en/latest/#a-note-on-resolvers
```
pip-compile --resolver=backtracking requirements.in
```
This resolver will automatically use `multiprocess` 0.70.13 version.
Using `set_format(type='torch', columns=columns)` makes Array2D/3D columns stop formatting correctly
State: closed | Author: plamb-viso (NONE)

I have a Dataset with two Features defined as follows:

```
'image': Array3D(dtype="int64", shape=(3, 224, 224)),
'bbox': Array2D(dtype="int64", shape=(512, 4)),
```

On said dataset, if I `dataset.set_format(type='torch')` and then use the dataset in a dataloader, these columns are correctly cast to Tensors of (batch_size, 3, 224, 244) for example.

However, if I `dataset.set_format(type='torch', columns=['image', 'bbox'])` these columns are cast to Lists of tensors and miss the batch size completely (the 3 dimension is the list length).

I'm currently digging through datasets formatting code to try and find out why, but was curious if someone knew an immediate solution for this.

Comments: In case others find this, the problem was not with set_format, but my usages of `to_pandas()` and `from_pandas()` which I was using during dataset splitting; somewhere in the chain of converting to and from pandas the `Array2D/Array3D` types get converted to series of `Sequence()` types
Type error when calling `map` over dataset containing 0-d tensors
State: closed | Author: phipsgabler (NONE)

### Describe the bug

0-dimensional tensors in a dataset lead to `TypeError: iteration over a 0-d array` when calling `map`.  It is easy to generate such tensors by using `.with_format("...")` on the whole dataset.

### Steps to reproduce the bug

```
ds = datasets.Dataset.from_list([{"a": 1}, {"a": 1}]).with_format("torch")
ds.map(None)
```

### Expected behavior

Getting back `ds` without errors.

### Environment info

Python 3.10.8
datasets 2.6.
torch 1.13.0

Comments: Hi! 

We could address this by calling `.item()` on such tensors to extract the value, but this would lose us the type, which could lead to storing the generated dataset in a suboptimal format. Considering this, I think the only proper fix would be implementing support for 0-D tensors on Apache Arrow's side (Arrow is the underlying format we use to store datasets on disk/in memory). WDYT @lhoestq?

I think we can just convert the item to a numpy typed scalar using `.numpy()` ?

For example this works:
```python
import numpy as np
import pyarrow as pa

assert pa.array([np.float64(1.0)]).type == pa.float64()
assert pa.array([np.float32(1.0)]).type == pa.float32()
assert pa.array([np.int32(1)]).type == pa.int32()
assert pa.array([np.int64(1)]).type == pa.int64()
```

And therefore it would work the same as for PyTorch N-D Tensors: convert to Numpy Array to keep the type in `_cast_to_python_objects`, then convert to Arrow
datasets.data_files.EmptyDatasetError: The directory at wikisql doesn't contain any data files
State: closed | Author: ScottM-wizard (NONE)

### Describe the bug

From these lines:

from datasets import list_datasets, load_dataset
dataset = load_dataset("wikisql","binary")

I get error message:
datasets.data_files.EmptyDatasetError: The directory at wikisql doesn't contain any data files

And yet the 'wikisql' is reported to exist via the list_datasets(). 

Any help appreciated. 



### Steps to reproduce the bug

From these lines:

from datasets import list_datasets, load_dataset
dataset = load_dataset("wikisql","binary")

I get error message:
datasets.data_files.EmptyDatasetError: The directory at wikisql doesn't contain any data files

And yet the 'wikisql' is reported to exist via the list_datasets(). 

Any help appreciated. 


### Expected behavior

Dataset should load. This same code used to work.

### Environment info

Mac OS

Comments: Fixed. Please close.

how to fix?i need your help
Q: Memory release when removing the column?
State: closed | Author: bayartsogt-ya (NONE)

### Describe the bug

How do I release memory when I use methods like `.remove_columns()` or `clear()` in notebooks?
```python
from datasets import load_dataset
common_voice = load_dataset("mozilla-foundation/common_voice_11_0", "ja", use_auth_token=True)
# check memory -> RAM Used (GB):  0.704 / Total (GB)  33.670
common_voice = common_voice.remove_columns(column_names=common_voice.column_names['train'])
common_voice.clear()
# check memory -> RAM Used (GB):  0.705 / Total (GB)  33.670
```

I tried `gc.collect()` but did not help

### Steps to reproduce the bug

1. load dataset
2. remove all the columns
3. check memory is reduced or not


[link to reproduce](https://www.kaggle.com/code/bayartsogtya/huggingface-dataset-memory-issue/notebook?scriptVersionId=110630567)

### Expected behavior

Memory released when I remove the column

### Environment info

- `datasets` version: 2.1.0
- Platform: Linux-5.15.65+-x86_64-with-debian-bullseye-sid
- Python version: 3.7.12
- PyArrow version: 8.0.0
- Pandas version: 1.3.5

Comments: Hi ! Datasets are memory mapped from your disk, i.e. they're not loaded in RAM. This is possible thanks to the Arrow data format.

Therefore the column you remove is not in RAM, so removing it doesn't cause the RAM to decrease.

Thanks for the explanation! @lhoestq 
I wonder since it is memory mapped, can we reduce or remove this memory map?

Yes you can `del common_voice` for example or wait for it to be garbage collected
Add SQL guide
State: closed | Author: stevhliu (MEMBER)

This PR adapts @nateraw's awesome SQL notebook as a guide for the docs!

Comments: The docs for this PR live [here](https://moon-ci-docs.huggingface.co/docs/datasets/pr_5223). All of your documentation changes will be reflected on that endpoint.

I think we may want more content on this page that's not SQL related. Some of that content probably already lives in the main `load` docs page, but might be bad to remove major things like csv/pandas from there...WDYT we should do @lhoestq ?

Maybe the main load page can only show one example and redirect to this page for more details ?

We can do the same for pandas stuff: have one example in load, and redirect to this page for more details

The docs for this PR live [here](https://moon-ci-docs.huggingface.co/docs/datasets/pr_5223). All of your documentation changes will be reflected on that endpoint.
HuggingFace website is incorrectly reporting that my datasets are pickled
State: closed | Author: ProGamerGov (CONTRIBUTOR)

### Describe the bug

HuggingFace is incorrectly reporting that my datasets are pickled. They are not picked, they are simple ZIP files containing PNG images.

Hopefully this is the right location to report this bug.

### Steps to reproduce the bug

Inspect my dataset respository here: https://huggingface.co/datasets/ProGamerGov/StableDiffusion-v1-5-Regularization-Images

### Expected behavior

They should not be reported as being pickled.

### Environment info

N/A

Comments: cc @McPatate maybe you know what's happening ?

Yes I think I know what is happening. We check in zips for pickles, and the UI must display the pickle jar when a scan has an associated list of imports, even when empty.
~I'll fix ASAP !~

>  I'll fix ASAP !

Actually I'd rather leave it like that for now, as it indicates that we checked for pickles and nothing dangerous appeared :)

Closing the issue with the typical "feature not a bug"
Cannot push 
State: closed | Author: bayartsogt-ya (NONE)

### Describe the bug

I am facing the issue when I try to push the tar.gz file around 11G to HUB.

```
(venv) ╭─laptop@laptop ~/PersonalProjects/data/ulaanbal_v0 ‹main●› 
╰─$ du -sh *
4.0K	README.md
 13G	data
516K	test.jsonl
 18M	train.jsonl
4.0K	ulaanbal_v0.py
 11G	ulaanbal_v0.tar.gz
452K	validation.jsonl

(venv) ╭─laptop@laptop~/PersonalProjects/data/ulaanbal_v0 ‹main●› 
╰─$ git add ulaanbal_v0.tar.gz && git commit -m 'large version'

(venv) ╭─laptop@laptop ~/PersonalProjects/data/ulaanbal_v0 ‹main●› 
╰─$ git push 
EOFoading LFS objects:   0% (0/1), 0 B | 0 B/s                                                                                                                                                      
Uploading LFS objects:   0% (0/1), 0 B | 0 B/s, done.
error: failed to push some refs to 'https://huggingface.co/datasets/bayartsogt/ulaanbal_v0'
```

I have already tried pushing a small version of this and it was working fine. So my guess it is probably because of the big file.

Following I run before the commit:
```
╰─$ git lfs install
╰─$ huggingface-cli lfs-enable-largefiles .
```

### Steps to reproduce the bug

Create a private dataset on huggingface and push 12G tar.gz file

### Expected behavior

To be pushed with no issue

### Environment info


- `datasets` version: 2.6.1
- Platform: Darwin-21.6.0-x86_64-i386-64bit
- Python version: 3.7.11
- PyArrow version: 10.0.0
- Pandas version: 1.3.5


Comments: Did you run `huggingface-cli lfs-enable-largefiles` before committing or before adding ? Maybe you can try before adding

Anyway I'd encourage you to split your data into several TAR archives if possible, this way the dataset can loaded faster using multiprocessing (by giving each process a subset of shards to process)

@lhoestq 
Thanks for the help!
> Maybe you can try before adding

It did not help

But I totally got your point about split into multiple TAR archives. It really helped!
Implicit type conversion of lists in to_pandas
State: closed | Author: sanderland (CONTRIBUTOR)

### Describe the bug

```
ds = Dataset.from_list([{'a':[1,2,3]}])
ds.to_pandas().a.values[0]
```
Results in `array([1, 2, 3])`  -- a rather unexpected conversion of types which made downstream tools expecting lists not happy.

### Steps to reproduce the bug

See snippet

### Expected behavior

Keep the original type

### Environment info

datasets 2.6.1
python 3.8.10

Comments: I think this behavior comes from PyArrow:
```python
import pyarrow as pa
t = pa.table({"a": [[0]]})
t.to_pandas().a.values[0]
# array([0])
```

I believe this has to do with zero-copy: you can get a pandas DataFrame without copying the buffers from arrow, and therefore end up with numpy arrays.

That's interesting, I guess not much to do here then.