As traduções são geradas por tradução automática. Em caso de conflito entre o conteúdo da tradução e da versão original em inglês, a versão em inglês prevalecerá.
Definição, sintaxe e comportamento de correspondência do grupo de pacotes
Este tópico contém informações sobre como definir grupos de pacotes, comportamento de correspondência de padrões, força de associação de pacotes e hierarquia de grupos de pacotes.
Sumário
Sintaxe e exemplos de definição de grupos de pacotes
A sintaxe padrão para definir grupos de pacotes segue de perto a formatação dos caminhos dos pacotes. Um caminho de pacote é criado a partir dos componentes de coordenadas de um pacote (formato, namespace e nome) adicionando uma barra no início e separando cada um dos componentes com uma barra. Por exemplo, o caminho do pacote npm nomeado no namespace é anycompany-ui-components/npm/space/. anycompany-ui-components
Um padrão de grupo de pacotes segue a mesma estrutura de um caminho de pacote, exceto que os componentes que não são especificados como parte da definição do grupo são omitidos e o padrão é encerrado com um sufixo. O sufixo incluído determina o comportamento correspondente do padrão, da seguinte forma:
Um
$sufixo corresponderá à coordenada completa do pacote.Um
~sufixo corresponderá a um prefixo.Um
*sufixo corresponderá a todos os valores do componente definido anteriormente.
Aqui estão exemplos de padrões para cada uma das combinações permitidas:
Todos os formatos de pacote:
/*Um formato de pacote específico:
/npm/*Formato do pacote e prefixo do namespace:
/maven/com.anycompany~Formato e namespace do pacote:
/npm/space/*Formato do pacote, namespace e prefixo do nome:
/npm/space/anycompany-ui~Formato, namespace e nome do pacote:
/maven/org.apache.logging.log4j/log4j-core$
Conforme mostrado nos exemplos acima, o ~ sufixo é adicionado ao final de um namespace ou nome para representar uma correspondência de prefixo e * vem depois de uma barra quando usado para combinar todos os valores do próximo componente no caminho (todos os formatos, todos os namespaces ou todos os nomes).
Definição e normalização do grupo de pacotes
CodeArtifact normaliza NuGet os nomes dos pacotes Python e Swift e normaliza os namespaces dos pacotes Swift antes de armazená-los. CodeArtifact usa esses nomes normalizados ao combinar pacotes com definições de grupos de pacotes. Portanto, grupos de pacotes que contêm um namespace ou nome nesses formatos devem usar o namespace e o nome normalizados. Para obter mais informações sobre como os nomes de pacotes e namespaces são normalizados, consulte a documentação de normalização de nomes em NuGetPython e Swift.
Namespaces nas definições de grupos de pacotes
Para pacotes ou formatos de pacotes sem um namespace (Python e NuGet), os grupos de pacotes não devem conter um namespace. A definição do grupo de pacotes para esses grupos de pacotes contém uma seção de namespace em branco. Por exemplo, o caminho para o pacote Python chamado requests é /python//requests.
Para pacotes ou formatos de pacotes com um namespace (Maven, genérico e Swift), o namespace deverá ser incluído se o nome do pacote estiver incluído. Para o formato de pacote Swift, o namespace do pacote normalizado será usado. Para obter mais informações sobre como os namespaces de pacotes Swift são normalizados, consulte. Normalização do nome e do namespace do pacote Swift
Hierarquia de grupos de pacotes e especificidade de padrões
Os pacotes que estão “em” ou “associados a” um grupo de pacotes são pacotes com um caminho de pacote que corresponde ao padrão do grupo, mas não corresponde ao padrão de um grupo mais específico. Por exemplo, dados os grupos de pacotes /npm/* e/npm/space/*, o caminho do pacote /npm//react está associado ao primeiro grupo (/npm/*), enquanto /npm/space/aui.components e /npm/space/ estão associados ao segundo grupo (). amplify-ui-core /npm/space/* Embora um pacote possa corresponder a vários grupos, cada pacote está associado somente a um único grupo, a correspondência mais específica, e somente a configuração de um grupo se aplica ao pacote.
Quando um caminho de pacote corresponde a vários padrões, o padrão “mais específico” pode ser considerado o padrão de correspondência mais longo. Como alternativa, o padrão mais específico é aquele que corresponde a um subconjunto adequado dos pacotes que correspondem ao padrão menos específico. Em nosso exemplo anterior, cada pacote que corresponde /npm/space/* também corresponde/npm/*, mas o inverso não é verdadeiro, o que torna /npm/space/* o padrão mais específico porque é um subconjunto adequado de/npm/*. Como um grupo é um subconjunto de outro grupo, ele cria uma hierarquia, na qual /npm/space/* está um subgrupo do grupo pai. /npm/*
Embora somente a configuração mais específica do grupo de pacotes se aplique a um pacote, esse grupo pode ser configurado para herdar da configuração do grupo principal.
Palavras, limites de palavras e correspondência de prefixos
Antes de discutir a correspondência de prefixos, vamos definir alguns termos-chave:
Uma palavra, uma letra ou número seguido por zero ou mais letras, números ou caracteres marcantes (como acentos, tremas etc.).
O limite de uma palavra está no final de uma palavra, quando um caractere que não é uma palavra é atingido. Caracteres que não são palavras são caracteres de pontuação
., como, e.-_
Especificamente, o padrão regex para uma palavra é[\p{L}\p{N}][\p{L}\p{N}\p{M}]*, que pode ser dividido da seguinte forma:
\p{L}representa qualquer letra.\p{N}representa qualquer número.\p{M}representa qualquer caractere de marca, como acentos, tremas etc.
Portanto, [\p{L}\p{N}] representa um número ou letra e [\p{L}\p{N}\p{M}]* representa zero ou mais letras, números ou caracteres de marca, e um limite de palavra está no final de cada correspondência desse padrão regex.
nota
A correspondência de limites de palavras é baseada nessa definição de “palavra”. Não é baseado em palavras definidas em um dicionário, ou CameCase. Por exemplo, não há limite de palavras em oneword ouOneWord.
Agora que a palavra e o limite da palavra estão definidos, podemos usá-los para descrever a correspondência de prefixos em. CodeArtifact Para indicar uma correspondência de prefixo no limite de uma palavra, um caractere de correspondência (~) é usado após um caractere de palavra. Por exemplo, o padrão /npm/space/foo~ corresponde aos caminhos do pacote /npm/space/foo e/npm/space/foo-bar, mas não ao /npm/space/food ou/npm/space/foot.
É necessário usar um curinga (*) em vez de seguir um caractere ~ que não seja uma palavra, como no padrão. /npm/*
Diferenciação de letras maiúsculas e minúsculas
As definições de grupos de pacotes diferenciam maiúsculas de minúsculas, o que significa que padrões que diferem somente por maiúsculas e minúsculas podem existir como grupos de pacotes separados. Por exemplo, um usuário pode criar grupos de pacotes separados com os padrões/npm//AsyncStorage$,/npm//asyncStorage$, e /npm//asyncstorage$ para os três pacotes separados que existem no Registro Público npm: AsyncStorage, AsyncStorage, asyncstorage que diferem apenas por maiúsculas e minúsculas.
Embora o caso seja importante, CodeArtifact ainda associa pacotes a um grupo de pacotes se o pacote tiver uma variação do padrão que difere de acordo com o caso. Se um usuário criar o grupo de /npm//AsyncStorage$ pacotes sem criar os outros dois grupos mostrados acima, todas as variações de maiúsculas e minúsculas do nome AsyncStorage, incluindo asyncStorage e asyncstorage, serão associadas ao grupo de pacotes. Mas, conforme descrito na próxima seçãoPartida forte e fraca, essas variações serão tratadas de forma diferente de AsyncStorage, o que corresponde exatamente ao padrão.
Partida forte e fraca
As informações na seção anterior,Diferenciação de letras maiúsculas e minúsculas, afirmam que os grupos de pacotes diferenciam maiúsculas de minúsculas e, em seguida, explicam que não fazem distinção entre maiúsculas e minúsculas. Isso ocorre porque as definições de grupos de pacotes CodeArtifact têm um conceito de correspondência forte (ou correspondência exata) e correspondência fraca (ou correspondência de variação). Uma combinação forte é quando a embalagem corresponde exatamente ao padrão, sem qualquer variação. Uma combinação fraca ocorre quando a embalagem corresponde a uma variação do padrão, como letras maiúsculas e minúsculas diferentes. O comportamento de correspondência fraco impede que pacotes que são variações do padrão de um grupo de pacotes sejam acumulados em um grupo de pacotes mais geral. Quando um pacote é uma variação (correspondência fraca) do padrão do grupo de correspondência mais específico, o pacote é associado ao grupo, mas o pacote é bloqueado em vez de aplicar a configuração de controle de origem do grupo, impedindo que novas versões do pacote sejam retiradas do upstreams ou publicadas. Esse comportamento reduz o risco de ataques à cadeia de suprimentos resultantes da confusão de dependências de pacotes com nomes quase idênticos.
Para ilustrar um comportamento fraco de correspondência, suponha que o grupo de pacotes /npm/* permita a ingestão e bloqueie a publicação. Um grupo de pacotes mais específico,/npm//anycompany-spicy-client$, está configurado para bloquear a ingestão e permitir a publicação. O nome do pacote anycompany-spicy-clienté uma combinação forte do grupo de pacotes, o que permite que as versões do pacote sejam publicadas e bloqueia a ingestão das versões do pacote. A única letra maiúscula do nome do pacote que pode ser publicada é anycompany-spicy-client, pois é uma forte correspondência com o padrão de definição do pacote. Uma variação de maiúsculas e minúsculas diferente, como AnyCompany-spicy-client, está impedida de publicar porque é uma correspondência fraca. Mais importante ainda, o grupo de pacotes bloqueia a ingestão de todas as variações de maiúsculas e minúsculas, não apenas do nome em minúsculas usado no padrão, reduzindo o risco de um ataque de confusão de dependências.
Variações adicionais
Além das diferenças entre maiúsculas e minúsculas, a correspondência fraca também ignora as diferenças nas sequências de traços-, pontos., sublinhados _ e caracteres confusos (como caracteres de aparência semelhante de alfabetos separados). Durante a normalização usada para correspondência fraca, CodeArtifact realiza a dobragem de maiúsculas e minúsculas (semelhante à conversão para minúsculas), substitui sequências de caracteres de traço, ponto e sublinhado por um único ponto e normaliza caracteres confusos.
A combinação fraca trata traços, pontos e sublinhados como equivalentes, mas não os ignora completamente. Isso significa que foo-bar, foo.bar, foo.. bar e foo_bar são todos equivalentes de correspondência fraca, mas foobar não. Embora vários repositórios públicos implementem etapas para evitar esses tipos de variações, a proteção fornecida pelos repositórios públicos não torna esse recurso de grupos de pacotes desnecessário. Por exemplo, repositórios públicos como o registro npm Public Registry só evitarão novas variações do pacote chamado my-package se my-package já estiver publicado nele. Se my-package for um pacote interno e /npm//my-package$ for criado um grupo de pacotes que permita a publicação e bloqueie a ingestão, você provavelmente não desejará publicar my-package no Registro Público npm para evitar que uma variante como my.package seja permitida.
Embora alguns formatos de pacote, como o Maven, tratem esses caracteres de forma diferente (o Maven trata . como um separador de hierarquia de namespace, mas não - ou_), algo como com.act-on ainda pode ser confundido com com.act.on.
nota
Observe que sempre que várias variações são associadas a um grupo de pacotes, um administrador pode criar um novo grupo de pacotes para uma variação específica para configurar um comportamento diferente para essa variação.
