O que aconteceu com o Databricks Repos?

O Azure Databricks lançou novos elementos da interface do usuário que permitem que os usuários trabalhem diretamente com pastas apoiadas por repositório Git a partir da interface do usuário do espaço de trabalho, substituindo efetivamente a funcionalidade anterior e separada do recurso "Repos".

O que essa mudança significa para mim?

Se você for um usuário do recurso Databricks Repos para controle de origem baseado em Git coversionado de ativos do projeto, a funcionalidade principal não foi alterada. A diferença mais notável é que muitas operações contextuais da interface do usuário agora se referem a "pastas Git" em vez de "Repos".

Por exemplo, uma pasta Databricks apoiada por um repositório Git pode ser criada selecionando Novo e, em seguida , Repositório na interface do usuário:

Agora, você seleciona Novo e escolhe a pasta Git. A mesma coisa, nome diferente!

Essa alteração fornece algumas melhorias que simplificam o trabalho com pastas controladas por versão:

1. Melhor organização de pastas: as pastas Git podem ser criadas em qualquer nível da árvore de arquivos do espaço de trabalho, permitindo que você organize suas pastas Git de uma maneira que funcione melhor para seu projeto. Por exemplo, você pode criar pastas Git em /Workspace/Users/<user email>/level_1/level_2/level_3/<Git folder name>. Os Repos só podem ser criados num nível de diretório fixo, como a raiz da pasta de utilizador dos Repos, como /Workspace/Repos/<user email>/<Repo name>.
   • Nota: As pastas Git podem conter ou estar localizadas junto a outros recursos que não são suportados pelo Repos atualmente. Tipos de ativos sem suporte, como ativos DBSQL e experimentos MLflow, podem ser movidos para pastas Git. O suporte de serialização para ativos adicionais será adicionado ao longo do tempo.
2. Comportamentos simplificados da interface do usuário: essa alteração traz uma interação comum do espaço de trabalho – trabalhar com o Git – diretamente para o espaço de trabalho do Databricks e reduz o tempo gasto navegando entre o espaço de trabalho e as pastas Git controladas por versão.

O que mudou, especificamente?

1. As pastas Git podem ser criadas fora do /Repos diretório.
2. As pastas Git são criadas selecionando Nova>pasta Git em um espaço de trabalho Databricks. Isso cria uma nova pasta Git em /Workspace/Users/<user-email>/.
3. As pastas Git podem ser criadas em várias profundidades da árvore de arquivos do espaço de trabalho, desde que estejam em /Workspace/Users/<user-email>. Por exemplo, você pode criar pastas Git em /Workspace/Users/<user-email>/level_1/level_2/level_3/<git-folder-name>. Você pode ter várias pastas Git em /Workspace/Users/<user-email>.
4. Ativos sem suporte são permitidos em pastas Git. O suporte à serialização para outros tipos de ativos será adicionado ao longo do tempo.
5. Ao contrário de Repos, você não pode criar uma nova pasta Git no Databricks sem uma URL de repositório remoto.

O que acontece para os meus repositórios atuais?

Se você tiver Repos definidos para seu espaço de trabalho do Azure Databricks, eles não desaparecerão e você não precisará migrar esses Repos existentes para pastas Git. Em vez disso, os repositórios foram integrados à interface do usuário do espaço de trabalho do Azure Databricks e não são mais apresentados como um conjunto separado de pastas organizadas em um nó Repo de nível superior. Agora eles podem ser encontrados na /Workspace pasta raiz como /Workspace/Repos.

• As referências existentes /Repos continuarão a funcionar. Os caminhos que começam com ou /Repos ou /Workspace/Repos referem-se à mesma pasta, e os caminhos declarados em jobs, dbutils.notebook.run e as referências em %run podem permanecer inalterados.
• Em um caso raro, você deve fazer uma modificação única em seu espaço de trabalho para que esse redirecionamento funcione. Para obter mais detalhes sobre essa modificação, consulte Referências a objetos de espaço de trabalho.

O Databricks recomenda que os usuários criem novas pastas Git em vez de Repos se precisarem se conectar ao controle de origem do Git a partir do espaço de trabalho Databricks. A colocalização de repositórios Git e outros ativos de espaço de trabalho torna as pastas Git mais detetáveis e fáceis de gerenciar do que os repositórios.

Permissões de pasta Git As pastas Git têm as mesmas permissões de pasta de espaço de trabalho que outras pastas de espaço de trabalho. Os usuários devem ter a permissão para executar a CAN_MANAGE maioria das operações do Git.

Qual DBR devo usar para executar código em pastas Git?

Para uma execução de código consistente entre pastas Git e repositórios herdados, o Databricks recomenda que os usuários executem código somente em pastas Git com DBR 15+.

Comportamento atual do diretório de trabalho (CWD)

O Databricks Runtime (DBR) versão 14 ou superior permite o uso de caminhos relativos e oferece a mesma experiência de diretório de trabalho atual (CWD) para todos os notebooks, permitindo a execução do notebook a partir do diretório de trabalho atual. Os comportamentos do diretório de trabalho atual (CWD) podem ser inconsistentes entre notebooks numa pasta Git e numa pasta não-Git nas versões mais antigas do Databricks Runtime (DBR).

Comportamento sys.path do Python

O Databricks Runtime (DBR) versão 14.3 ou superior fornece o mesmo sys.path comportamento em pastas Git como em repositórios herdados. Com as versões anteriores do DBR, o comportamento das pastas Git difere das Repos herdadas, pois o diretório raiz do repositório não é automaticamente adicionado a sys.path para pastas Git. Para Python, sys.path contém uma lista de diretórios que o interpretador pesquisa ao importar módulos. Se não puder usar o DBR 15 ou superior, pode anexar manualmente um caminho de pasta a sys.path como solução alternativa.

Para obter exemplos sobre como adicionar diretórios ao sys.path usando caminhos relativos, consulte Importar módulos Python e R.

Precedência da biblioteca Python

Databricks Runtime (DBR) versão 14.3 ou superior fornece a mesma precedência da biblioteca Python em pastas Git como nos repositórios herdados.