

Le traduzioni sono generate tramite traduzione automatica. In caso di conflitto tra il contenuto di una traduzione e la versione originale in Inglese, quest'ultima prevarrà.

# Utilizzo del codice modulare con il decoratore @remote
<a name="train-remote-decorator-modular"></a>

È possibile organizzare il codice in moduli per facilitare la gestione dell'area di lavoro durante lo sviluppo e continuare a utilizzare la funzione @remote per richiamare una funzione. È inoltre possibile replicare i moduli locali dall'ambiente di sviluppo all'ambiente di lavoro remoto. A tal fine, imposta il parametro `include_local_workdir` su `True`, come visualizzato nell'esempio di codice seguente.

```
@remote(
  include_local_workdir=True,
)
```

**Nota**  
Il decoratore e il parametro @remote devono apparire nel file principale, anziché in uno qualsiasi dei file dipendenti.

Quando `include_local_workdir` è impostato su`True`, SageMaker AI impacchetta tutti gli script Python mantenendo la struttura di directory nella directory corrente del processo. Inoltre, rende disponibili le dipendenze nella directory di lavoro del processo.

Ad esempio, si supponga che lo script Python che elabora il set di dati MNIST sia diviso in uno script `main.py` e uno script `pytorch_mnist.py` dipendente. `main.py` chiama lo script dipendente. Inoltre, lo script `main.py` contiene il codice per importare la dipendenza come mostrato.

```
from mnist_impl.pytorch_mnist import ...
```

Il file `main.py` deve contenere anche il decoratore `@remote` e deve impostare il parametro `include_local_workdir` su `True`.

Per impostazione predefinita, il parametro `include_local_workdir` include tutti gli script Python nella directory. È possibile personalizzare i file che si desidera caricare nel processo utilizzando questo parametro insieme al parametro `custom_file_filter`. È possibile passare una funzione che filtra le dipendenze dei processi da caricare su S3 o un oggetto `CustomFileFilter` che specifica le directory e i file locali da ignorare nella funzione remota. È possibile utilizzare `custom_file_filter` solo se `include_local_workdir` è impostato su `True`, altrimenti il parametro viene ignorato.

L’esempio seguente utilizza `CustomFileFilter` per ignorare tutti i file e le cartelle del notebook o i file denominati `data` durante il caricamento di file su S3.

```
@remote(
   include_local_workdir=True,
   custom_file_filter=CustomFileFilter(
      ignore_name_patterns=[ # files or directories to ignore
        "*.ipynb", # all notebook files
        "data", # folter or file named data
      ]
   )
)
```

L’esempio seguente mostra come creare un pacchetto di un intero spazio di lavoro.

```
@remote(
   include_local_workdir=True,
   custom_file_filter=CustomFileFilter(
      ignore_pattern_names=[] # package whole workspace
   )
)
```

L’esempio seguente mostra come utilizzare una funzione per filtrare i file.

```
import os

def my_filter(path: str, files: List[str]) -> List[str]:
    to_ignore = []
   for file in files:
       if file.endswith(".txt") or file.endswith(".ipynb"):
           to_ignore.append(file)
   return to_ignore

@remote(
   include_local_workdir=True,
   custom_file_filter=my_filter
)
```

## Migliori pratiche per strutturare la directory di lavoro
<a name="train-remote-decorator-modular-bestprac"></a>

Le best practice seguenti suggeriscono come organizzare la struttura di directory utilizzando il decoratore `@remote` nel codice modulare.
+ Colloca il decoratore @remote in un file che si trova nella directory di livello principale dell'area di lavoro.
+ Struttura i moduli locali a livello principale.

L'immagine di esempio seguente mostra la struttura di directory consigliata. In questa struttura di esempio, lo script `main.py` si trova nella directory di livello principale.

```
.
├── config.yaml
├── data/
├── main.py <----------------- @remote used here 
├── mnist_impl
│ ├── __pycache__/
│ │ └── pytorch_mnist.cpython-310.pyc
│ ├── pytorch_mnist.py <-------- dependency of main.py
├── requirements.txt
```

L'immagine di esempio seguente mostra una struttura di directory che si tradurrà in un comportamento incoerente quando viene utilizzata per annotare il codice con un decoratore @remote. 

In questa struttura di esempio, lo script `main.py` che contiene il decoratore @remote **non** si trova nella directory di livello principale. La seguente struttura **NON** è consigliata.

```
.
├── config.yaml
├── entrypoint
│ ├── data
│ └── main.py <----------------- @remote used here
├── mnist_impl
│ ├── __pycache__
│ │ └── pytorch_mnist.cpython-310.pyc
│ └── pytorch_mnist.py <-------- dependency of main.py
├── requirements.txt
```