Cargo-edit: `cargo add`: inclui apenas MAJOR.MINOR

Por quê?

Por quê?

Por que, por exemplo, semver e regex são especificados neste formulário no Cargo.toml do cargo-edit? :cara de gozo:

Normalmente, você deseja especificar um nível mínimo de recurso necessário, então, por exemplo, docopt usa este modelo.

Eu preferiria perguntar por que você deseja especificar a versão completa?

Bons pontos!

Se adicionar dependências manualmente, tendo a omitir a versão do patch, exceto se
é 0.xe sei que este recurso foi adicionado recentemente, como regex = "0.1.66" .

Do ponto de vista prático, isso é estética, porém: 1.2.3 e 1.2 e
1 carregará todos 1.4.9 (se essa for a versão mais recente), como a carga interpreta
isso como ^1.2.3 etc.

Do ponto de vista pessimista: 1.2.0 a 1.2.2 provavelmente têm erros
versões - por que mais eles publicariam um 1.2.3? Então, vamos ter certeza de que nós (e
esperançosamente, além de outras dependências) estão usando a versão absolutamente mais recente!

Como você pode ver, parece haver bons argumentos para ambos os lados - e eu adoraria
para ouvir mais um pouco antes de decidir!

Andronik Ordian [email protected] schrieb am Do. 29 de junho de 2017 um
01:18:

Por quê?

Por que, por exemplo, semver e regex são especificados neste formulário no cargo-edit's
Cargo.toml? [imagem:: trollface:]

Normalmente, você deseja especificar um nível mínimo de recurso necessário, então, por exemplo
docopt https://github.com/docopt/docopt.rs/blob/master/Cargo.toml usa
este modelo.

Eu preferiria perguntar por que você deseja especificar a versão completa?

-
Você está recebendo isto porque comentou.

Responda a este e-mail diretamente, visualize-o no GitHub
https://github.com/killercup/cargo-edit/issues/126#issuecomment-311818430 ,
ou silenciar o tópico
https://github.com/notifications/unsubscribe-auth/AABOX0xJ-m_uioA7lhD29mlL6mlAvgvEks5sIt9DgaJpZM4OIifr
.

Do ponto de vista prático, isso é estética, porém: 1.2.3 e 1.2 e
1 carregará todos 1.4.9 (se essa for a versão mais recente), como a carga interpreta
isso como ^1.2.3 etc.

Eu diria que 1,2 é melhor do que 1 porque o último não especifica o conjunto mínimo de recursos, enquanto o primeiro o faz.

Do ponto de vista pessimista: 1.2.0 a 1.2.2 provavelmente têm erros
versões - por que mais eles publicariam um 1.2.3? Então, vamos ter certeza de que nós (e
esperançosamente, além de outras dependências) estão usando a versão absolutamente mais recente!

Considere o seguinte exemplo. Em algum ponto, você adiciona uma dependência X por meio de adição de carga, digamos 1.2.1.
Mais tarde, um bug no X foi encontrado. Mas você se esqueceu de atualizar a dependência. Nesse cenário, 1.2.1 é pior do que 1.2, porque 1.2 só será compilado para a versão mais recente.

Eu diria que 1,2 é melhor do que 1 porque o último não especifica o conjunto mínimo de recursos, enquanto o primeiro o faz.

Verdadeiro. Mas você pode facilmente argumentar que 1.2.3 é melhor do que 1.2 porque o último não especifica o nível mínimo de patches que fazem o recurso necessário funcionar enquanto o primeiro o faz :)

Nesse cenário, 1.2.1 é pior do que 1.2, porque 1.2 só será compilado para a versão mais recente.

Se bem entendi, isso é falso, na verdade. Assumindo

Mas você se esqueceu de atualizar a dependência.

significa que você já tem a versão de dependência fixada em seu Cargo.lock, ambos agem da mesma forma. E cargo update atualizará ambos para a versão mais recente <2.0.0. Cargo assume ^ default, veja isto para detalhes.

Verdadeiro. Mas você pode facilmente argumentar que 1.2.3 é melhor do que 1.2 porque o último não especifica o nível mínimo de patches que fazem o recurso necessário funcionar enquanto o primeiro o faz :)

Verdade, mas apenas se você contar com a correção do bug.

Se bem entendi, isso é falso, na verdade.

Sim, meu cérebro não funcionava tarde da noite. Me desculpe por isso.

Então, o que você estava dizendo no ponto pessimista é que se tivermos uma dependência transitiva X = "= 1.2.0" e se especificarmos a dependência direta X = "1.2" - ele irá compilar, enquanto com X = "1.2.3 "não vai, obrigando-nos a atualizar a dependência transitiva? Eu acho que este é um exemplo bastante artificial.

Em resumo, acho que adicionar uma opção para remover a versão do patch não fará mal.
Além disso, adicionar uma opção para não bagunçar todo o Cargo.toml: rofl: (mas esse é o problema diferente).

Em resumo, acho que adicionar uma opção para remover a versão do patch não fará mal.

Machucar? Não. Mas é mais uma coisa a manter, e ainda não vi motivo para me preocupar. Existem outras pessoas que também querem ter isso?

uma opção para não bagunçar todo o Cargo.toml

Não! Não é uma _opção_! O padrão! E sem --mess flag 😄 (cf. # 15)

Eu encontrei este tíquete porque geralmente só registro major.minor em meus arquivos manuais do Cargo.toml porque achei que era a coisa recomendada a fazer. O único caso em que posso ver isso mudando o comportamento funcional é se alguém publicasse e então arrancasse uma versão de uma caixa (por exemplo, se um patch de otimização foi aplicado, mas depois foi descoberto que introduzia uma falha de segurança ou regressão) - neste O caso de especificar a versão do patch evitaria que a biblioteca fosse construída se alguém apenas fizesse o check-out até que uma versão mais nova da biblioteca fosse publicada.

No entanto, ele muda a forma como é lido, já que ter três em vez de dois números sugere que o autor da biblioteca escolheu muito especificamente esse número de patch e mais recente, ao invés de simplesmente escolher o patch mais recente dos números maior-menores.

No entanto, como alternativa, você pode olhar para Cargo.toml mais como um registro do que como uma especificação com a qual o autor construiu a biblioteca pela última vez. No entanto, isso parece mais um dever do Cargo.lock, e o resto das informações em Cargo.toml parece geralmente ser uma definição o mais mínima possível do que é a biblioteca e como ela deve ser construída.

EDIT: NB que eu encontrei isso depois de executar o comando cargo upgrade, não cargo add, mas eu esperava que os dois comandos tivessem a mesma convenção (dois ou três pontos de versão).

Eu encontrei outro problema hoje - usar a atualização de carga restringe mais fortemente o gráfico de dependência em comparação com usar apenas "major.minor". Tive que retroceder serde e tokio_core em uma versão (por exemplo, 1.0.38 a 1.0.37) por causa das bibliotecas dependentes com as quais isso entrou em conflito.

Eu definitivamente apreciaria uma opção em cargo add e cargo upgrade para manter as especificações de informações mínimas.

É uma verruga muito pequena, mas eu prefiro manter todas as minhas versões de dependência como 0.4 ou 1 vez de especificar mais detalhes e, assim, acabar editando Cargo.toml manualmente após cada uso de um comando cargo-edit para remover as versões secundárias e de patch.

Tentei cargo upgrade pela primeira vez hoje e também sou uma dessas pessoas que prefere manter 1 e 0.4 vez de major.minor.patch. 😃

Eu irei gritar como a favor da edição de carga mantendo o número de versão mais específico possível. Estou feliz que ele usa o nível de patch atual ...

Na verdade, eu adoraria se houvesse uma maneira de retroceder nas versões para encontrar a versão mais antiga utilizável / compatível de uma dependência para que meus requisitos sejam os mais flexíveis para as pessoas que usam minha caixa.

Encontrar a versão mais antiga certamente é uma má ideia porque:

• faltarão possíveis correções de bugs e patches de segurança;
• se for uma caixa -sys ou se depender transitivamente de uma caixa -sys, e alguma outra dependência do usuário de sua caixa depender de uma versão mais recente dessa caixa -sys vinculado a uma versão mais recente da biblioteca nativa, eles ganharão ' t ser capaz de construir sua biblioteca, pois a carga recusará a vinculação em duas versões diferentes da biblioteca nativa. Eu acertei este com openssl , uma das dependências da minha caixa estava desatualizada e dependia transitivamente de um openssl-sys antigo e outra das dependências da minha caixa tinha até sua versão mais antiga dependendo de um openssl-sys mais recente

@YaLTeR Não concordo com sua avaliação porque parece não levar em consideração a lógica de resolução do Cargo.

Se minha caixa A depende da libc 0.0.1 e outra caixa B depende de 0.0.2 , uma terceira caixa C, dependendo de A e B, usará 0.0.2 perfeitamente. O usuário obtém o máximo possível de correções de bugs.

Colocar 0.0.1 no Cargo.toml não exige que uma versão específica seja escolhida, apenas uma sempre compatível com ela. Consulte a documentação do twox-hash é compatível com rand 0.3.10, 0.4.x e 0.5.x porque a superfície da API necessária não mudou nessas versões. Não há razão para eu ser incompatível com outra caixa que requer rand 0,4 e força o usuário a atualizar para 0,5.

e outra das dependências da minha caixa tinha até sua versão mais antiga dependendo de um openssl-sys mais recente

Esse é o problema que estou defendendo para evitar. Se essa caixa fosse compatível com as versões mais antigas e mais recentes e a especificasse no Cargo.toml, você não teria o problema em primeiro lugar .

Hmm, sim, bom ponto. Existe uma maneira de forçar uma caixa com um requisito como twox-hash es para usar uma versão específica e não a mais recente da caixa depentent?

uma caixa com um requisito como twox-hash es

Em um projeto que usa twox-hash e uma dependência lateral, o Cargo escolherá várias versões (por qualquer motivo), mas você pode optar por unificá-las:

`` `
$ cat Cargo.toml
[dependências]
twox-hash = "1.1.1"
rand = "0,4"

árvore de carga $
ex v0.1.0 (arquivo: /// private / tmp / ex)
├── rand v0.4.3
│ └── libc v0.2.43
└── twox-hash v1.1.1
└── rand v0.5.5
├── libc v0.2.43 (*)
└── rand_core v0.2.1

$ cargo update -p rand: 0.5.5 --precise 0.4.3

árvore de $ cargo
ex v0.1.0 (arquivo: /// private / tmp / ex)
├── rand v0.4.3
│ └── libc v0.2.43
└── twox-hash v1.1.1
└── rand v0.4.3 (*)

Na verdade, eu adoraria se houvesse uma maneira de retroceder nas versões para encontrar a versão mais antiga utilizável / compatível de uma dependência para que meus requisitos sejam os mais flexíveis para as pessoas que usam minha caixa.

Se este comportamento for fornecido, eu ficaria feliz em não ter suporte para MAJOR.MINOR sem patch.

Até que tenhamos isso, no entanto, vou continuar pressionando pela opção de excluir o patch e, possivelmente, versões menores.

O principal motivo de eu remover o patch é que ele é bastante arbitrário. 99% das vezes é apenas a versão de patch mais recente quando adicionei a dependência. Geralmente nem mesmo representa os recursos usados, já que eu poderia facilmente acabar dependendo de recursos mais novos sem atualizar a versão do patch - eu apenas atualizaria a versão realmente usada em Cargo.lock . Eu nunca atualizaria as versões do patch em qualquer caso, pois isso cria commits e churn sem motivo! Alguém usando cargo update no projeto final obterá a versão compatível mais recente de todas as minhas dependências de qualquer maneira.

Eu prefiro listar o menos específico que ainda tem informações sempre porque informações adicionais (versão MINOR se MAJOR> 0, ou PATCH se MAJOR.MINOR> 0) são, na melhor das hipóteses, inúteis e, na pior, totalmente incorretas.

Eu poderia facilmente acabar dependendo de recursos mais recentes sem atualizar a versão do patch

Eu recomendo adicionar uma linha ao seu IC para evitar isso:

cargo +nightly -Z minimal-versions test

versão em Cargo.lock

Acho que não disse isso explicitamente, mas estou preocupado principalmente com bibliotecas . Para binários que não parece como se realmente importa o que você colocar na sua Cargo.toml , porque há um Cargo.lock .

@shepmaster

Eu realmente deveria adquirir o hábito de usar minimal-versions . Só não atualizei as configurações de CI desde que se tornou uma coisa. Obrigado por mencionar isso.

Se conseguirmos isso e "atualizar para a versão mínima que ainda compila e passa nos testes", seria bom abandonar isso totalmente.

Eu estava considerando caixas binárias também porque sigo o mesmo princípio de excluir versões de patch para elas, e esse problema também é um problema para elas. Sim, não importa tanto o que está em Cargo.toml , mas isso é ainda mais razão para não incluir versões desnecessárias e semi-arbitrárias.

Outra preocupação que tenho com versões como no exemplo twox-hash : você provavelmente está desenvolvendo e testando a caixa na versão mais recente (rand 0,5 neste exemplo), então você pode acidentalmente começar a usar uma API que não era t coberto por versões anteriores (0.3 ou 0.4) sem perceber. Isso significa que agora você precisa essencialmente testar cada combinação de cada versão de uma dependência como essa? @shepmaster

EDITAR: também por que isso foi marcado como wontfix? ..

você provavelmente está desenvolvendo

Sim, provavelmente

e testando a caixa na versão mais recente

Veja meu comentário anterior para uma maneira de testar isso.

Isso significa que agora você precisa essencialmente testar cada combinação de cada versão de uma dependência como essa?

Como o semver é uma construção humana e não algo exigido pelo compilador, tecnicamente sim, você sempre precisaria testar todas as versões possíveis para ter certeza. Eu adoto uma abordagem mais prática e confio que outros desenvolvedores acertem na maioria das vezes.

Observe que esse já é um problema que você pode enfrentar. Se você colocar itertools = "1.0" em seu Cargo.toml, como sugerido por este problema, você está dizendo que seu código funciona com 1.0.0, que parece mais provavelmente incorreto do que itertools = "1.2.35" . O comportamento atual, de escolher a versão atual, tem a vantagem de que seu código foi testado com a versão da caixa que você especificou em um determinado momento.

A maioria das configurações de CI garantem que você trabalhe com as versões mais recentes de todos os engradados possíveis (uma vez que o arquivo de bloqueio não está confirmado, você resolve novamente a cada execução). É possível verificar a versão mais antiga de cada caixa possível por meio de -Z minimal-versions . Não conheço nenhuma maneira de verificar todas as permutações 😉

Eu adoto uma abordagem mais prática e confio que outros desenvolvedores acertem na maioria das vezes.

Sim, mas no caso de um requisito como >= 0.3, < 0.6 é perfeitamente válido para, por exemplo, 0,5 para adicionar alguma nova API que você pode começar a usar sem perceber que não estava disponível em 0.3. Suponho que -Z minimal-versions seja de grande ajuda aqui.

Queria continuar com isso porque está ficando um pouco velho para continuar precisando remover manualmente a revisão de todas as dependências em meu arquivo Cargo.toml . Há algum plano para ignorar isso e permitir apenas versões principais e secundárias nesta caixa?

Não tenho tempo para trabalhar nisso, mas posso revisar um PR se alguém quiser implementar isso.

Eu pensei para todos neste tópico. Além da especificação ou limite major.minor, também ajudaria ter a opção de fazer curingas?

Eu abri uma possível solução para isso, gostaria de receber comentários dos mantenedores, bem como de qualquer pessoa interessada neste recurso

Eu acho que isso seria melhor feito em uma base por projeto ou via sinalização de linha de comando quando você adiciona ou atualiza algo.

Eu acho que isso provavelmente seria devido à política de projeto do projeto adicionando as dependências; ou o projeto do qual depende. Alguns projetos podem se preocupar mais com a compatibilidade com versões anteriores do que outros e aderir a ela ou controlá-la melhor.

Diferentes usuários abrem a porta para a possibilidade de que um usuário obtenha um resultado diferente com a atualização de carga do que outro usuário ou o CI involuntariamente e isso pode causar rotatividade desnecessária, especialmente para projetos que recebem contribuições de mantenedores incidentais. Especialmente se cada desenvolvedor trabalhar em vários projetos que têm políticas diferentes sobre como desejam gerenciar seu .toml.

via sinalização de linha de comando quando você adiciona ou atualiza algo

Eu concordo. Um dos principais motivos é como o Cargo trata 1.x.y vs 0.x.y .

• Se eu especificar foo = "1.1" , isso inclui 1.1.0 , 1.1.1 e 1.99.99 .
• Se eu especificar foo = "0.1" , isso inclui 0.1.0 , 0.1.1 , mas não 0.99.99 .

Nos últimos dias, tive alguns pensamentos não refinados sobre isso ...

• Eu realmente gostaria que o ecossistema Rust pressionasse mais as dependências mínimas para bibliotecas.
• Isso se aplica a versões e recursos
• Na verdade, eu gostaria que cargo add escolhesse o conjunto mínimo de versões / recursos que funcionam para o meu código
• Considerando que geralmente adiciono a dependência antes de escrever o código, isso pode ser difícil
• Devemos usar restrições de versão mais complicadas com mais freqüência. Por exemplo, ter a restrição como ^1.2.19, ^1.3.4, ^1.4 não deve ser estranho para nós (embora isso dependa de bibliotecas que mantêm ativamente versões simultâneas)