Uso de código modular con el decorador @remote

Puede organizar el código en módulos para facilitar la gestión del espacio de trabajo durante el desarrollo y siga utilizando la función @remote para invocar una función. También puede replicar los módulos locales desde su entorno de desarrollo al entorno de trabajo remoto. Para ello, establezca el parámetro include_local_workdir en True, como se muestra en el siguiente ejemplo de código.

@remote(
  include_local_workdir=True,
)

nota

El decorador @remote y el parámetro deben aparecer en el archivo principal y no en ninguno de los archivos dependientes.

Cuando include_local_workdir se establece enTrue, SageMaker empaqueta todos los scripts de Python mientras mantiene la estructura de directorios en el directorio actual del proceso. También hace que las dependencias estén disponibles en el directorio de trabajo del trabajo.

Por ejemplo, supongamos que la secuencia de comandos de Python que procesa el MNIST conjunto de datos se divide en una main.py secuencia de comandos y una secuencia de pytorch_mnist.py comandos dependiente. main.pyllama al script dependiente. Además, el main.py script contiene código para importar la dependencia, como se muestra.

from mnist_impl.pytorch_mnist import ...

El main.py archivo también debe contener el @remote decorador y debe establecer el include_local_workdir parámetro en. True

El include_local_workdir parámetro incluye de forma predeterminada todos los scripts de Python del directorio. Puede personalizar los archivos que desea cargar en el trabajo utilizando este parámetro junto con el custom_file_filter parámetro. Puede pasar una función que filtre las dependencias de los trabajos para cargarlas en S3 o un CustomFileFilter objeto que especifique los directorios y archivos locales que se deben ignorar en la función remota. custom_file_filterSolo se puede usar si include_local_workdir está establecido enTrue; de lo contrario, se ignora el parámetro.

En el siguiente ejemplo, se CustomFileFilter omiten todos los archivos y carpetas del bloc de notas o los archivos con nombre data al cargar los archivos en S3.

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

En el siguiente ejemplo, se muestra cómo se puede empaquetar un espacio de trabajo completo.

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

El siguiente ejemplo muestra cómo se puede utilizar una función para filtrar archivos.

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
)

Prácticas recomendadas para estructurar el directorio de trabajo

Las siguientes prácticas recomendadas sugieren cómo organizar la estructura de directorios mientras se utiliza el @remote decorador en el código modular.

• Coloque el decorador @remote en un archivo que se encuentre en el directorio raíz del espacio de trabajo.

• Estructure los módulos locales en el nivel raíz.

En la siguiente imagen de ejemplo se muestra la estructura de directorios recomendada. En esta estructura de ejemplo, el script main.py se encuentra en el directorio raíz.

.
├── 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

En la siguiente imagen de ejemplo se muestra una estructura de directorios que provocará un comportamiento incoherente cuando se utilice para anotar el código con un decorador @remote.

En esta estructura de ejemplo, el script main.py que contiene el decorador @remote no se encuentra en el directorio raíz. Se NOTrecomienda la siguiente estructura.

.
├── 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