NeuralNetTorch Hyperparameter Tuning Fails with URI Scheme Error in PyArrow

[giladrubin1]

Bug Report Checklist

[V] I provided code that demonstrates a minimal reproducible example.
[X] I confirmed bug exists on the latest mainline of AutoGluon via source install.
[V] I confirmed bug exists on the latest stable version of AutoGluon.
Describe the bug

When attempting to run hyperparameter tuning with NN_TORCH as the model on a TabularDataset, an exception is thrown related to URI handling by pyarrow library. The error message indicates an "ArrowInvalid: URI has empty scheme".

Expected behavior

The training should proceed without errors, and the model should handle the URI scheme appropriately or provide more specific guidance on expected URI formats.

To Reproduce

Install a fresh environment with Python 3.10 and AutoGluon 1.1.0
Run the following script:

from autogluon.tabular import TabularDataset, TabularPredictor

data_url = 'https://raw.githubusercontent.com/mli/ag-docs/main/knot_theory/'
train_data = TabularDataset(f'{data_url}train.csv')
label = 'signature'
hp_args = {"num_trials": 3, "scheduler": "local", "searcher": "random"}
fit_args = {"hyperparameter_tune_kwargs": hp_args, "included_model_types": ["NN_TORCH"]}
predictor = TabularPredictor(label=label).fit(train_data, **fit_args)

Screenshots / Logs

Logs from the error:

pyarrow.lib.ArrowInvalid: URI has empty scheme: 'AutogluonModels/ag-20240509_084509/models

Installed Versions

INSTALLED VERSIONS ------------------ date : 2024-05-09 time : 08:47:49.707205 python : 3.10.14.final.0 OS : Linux OS-release : 5.15.0-1040-azure Version : #47~20.04.1-Ubuntu SMP Fri Jun 2 21:38:08 UTC 2023 machine : x86_64 processor : x86_64 num_cores : 16 cpu_ram_mb : 128812.6796875 cuda version : None num_gpus : 0 gpu_ram_mb : [] avail_disk_size_mb : 4284286

accelerate : 0.21.0
autogluon : 1.1.0
autogluon.common : 1.1.0
autogluon.core : 1.1.0
autogluon.features : 1.1.0
autogluon.multimodal : 1.1.0
autogluon.tabular : 1.1.0
autogluon.timeseries : 1.1.0
boto3 : 1.34.101
catboost : 1.2.5
defusedxml : 0.7.1
evaluate : 0.4.2
fastai : 2.7.15
gluonts : 0.14.3
hyperopt : 0.2.7
imodels : None
jinja2 : 3.1.4
joblib : 1.4.2
jsonschema : 4.21.1
lightgbm : 4.3.0
lightning : 2.1.4
matplotlib : 3.8.4
mlforecast : 0.10.0
networkx : 3.3
nlpaug : 1.1.11
nltk : 3.8.1
nptyping : 2.4.1
numpy : 1.26.4
nvidia-ml-py3 : 7.352.0
omegaconf : 2.2.3
onnxruntime-gpu : None
openmim : 0.3.9
optimum : 1.18.1
optimum-intel : None
orjson : 3.10.3
pandas : 2.2.2
pdf2image : 1.17.0
Pillow : 10.3.0
psutil : 5.9.8
pytesseract : 0.3.10
pytorch-lightning : 2.1.4
pytorch-metric-learning: 2.3.0
ray : 2.10.0
requests : 2.28.2
scikit-image : 0.20.0
scikit-learn : 1.4.0
scikit-learn-intelex : None
scipy : 1.12.0
seqeval : 1.2.2
setuptools : 60.2.0
skl2onnx : None
statsforecast : 1.4.0
tabpfn : None
tensorboard : 2.16.2
text-unidecode : 1.3
timm : 0.9.16
torch : 2.1.2
torchmetrics : 1.2.1
torchvision : 0.16.2
tqdm : 4.65.2
transformers : 4.38.2
utilsforecast : 0.0.10
vowpalwabbit : None
xgboost : 2.0.3

[Innixma]

Good find @giladrubin1! I was able to reproduce the issue.

The cause is from ultralytics/ultralytics#4980 (comment)

Specifically, we are using a relative path for Ray's storage_path, but from Ray 2.7+, this was changed to only work with an absolute path. I've updated this and it has fixed the issue. The PR for the fix is #4232.