Aprenda sobre módulos da linguagem Golang. Como Go gerencia dependências. Descubra pacotes da linguagem. Aprenda como fazer o seu próprio módulo / biblioteca de Golang com um repositório de Git.

Módulos de Golang: Gerenciamento de Pacotes e Dependências na Linguagem Go

Módulos de Golang / Go: Como São Definidos

```markdown
# Resumo da Aula sobre Módulos em Go

Nesta aula, o instrutor discutiu os módulos da linguagem de programação Go, incluindo como definir e usar módulos no código fonte.

## Introdução aos Módulos de Go
- **Biblioteca Padrão**: Go possui uma biblioteca padrão que inclui vários pacotes, como `FMT` e `strings`.
- **Pacotes de Terceiros**: Além da biblioteca padrão, existem pacotes criados por terceiros, que são agrupados em módulos.

## Importação de Módulos
- Módulos podem ser importados no código Go com a palavra-chave `import`.
- Eles são geralmente armazenados em repositórios de controle de versão, como o GitHub.

## Exemplo de Módulo: GorillaMux
- O GorillaMux é um exemplo de módulo para gerenciamento de rotas em servidores web.
- O repositório contém o arquivo `go.mod`, que define o caminho do módulo e a versão mínima do Go requerida.

### Estrutura de um Módulo
- O arquivo `go.mod` contém:
  - A especificação do módulo com a palavra-chave `module`.
  - A versão mínima do Go necessária.
  - Dependências do módulo, se existirem.
  
- Exemplos de pacotes em um módulo:
  - O GorillaMux tem um único pacote, enquanto o Go Ethereum possui múltiplos pacotes (`Core`, `GraphQL`).

## Dependências de Módulos
- Dependências podem ser diretas ou indiretas.
- O Go utiliza um sistema de versionamento semântico, que organiza as versões em maior, menor e patch.
  
### Arquivo `go.sum`
- Um arquivo `go.sum` é gerado automaticamente para garantir que as versões das dependências sejam consistentes entre diferentes desenvolvedores.

## Conclusão
- O Go permite a criação descentralizada de módulos.
- Nele, todas as dependências são compiladas no executável final, eliminando a necessidade de vinculação externa.
- Módulos em Go são definidos com um arquivo `go.mod`, que contém informações essenciais sobre o módulo e suas dependências.

A aula termina com a recomendação de criar repositórios com um arquivo `go.mod` para facilitar o uso e importação de pacotes na linguagem Go.
```


Olá pessoal, esta aula vou falar sobre módulos de Go, falar de como o módulo de Go é definido
no código fonte.
Vamos começar aqui na página oficial da linguagem.
Eu cliquei em packages, pacotes e temos aqui a standard library, a biblioteca padrão
da linguagem de Go lang.
Temos vários módulos aqui, na biblioteca padrão, por exemplo, o famoso FMT está aqui,
certo?
Esse pacote FMT, cadê os strings?
Tem os strings e assim por diante.
Então, esses pacotes todos aqui são a biblioteca padrão, mas é claro que a gente só não
usa pacotes da biblioteca padrão, a gente usa pacotes escritos por outras pessoas, por
terceiros, né?
Então, pacotes de terceira pessoa também existem.
Então, no mundo do Go, esses pacotes são aglomerados em o que se chama módulo de Go.
E esse módulo pode ser importado através do palavra chave import, né?
No código fonte.
Agora, esses módulos são armazenados dentro de um repositório, né?
De controle de versão.
Popularmente, hoje em dia, é usando o get, né?
Então, vamos aqui a um exemplo.
Você já usou GorillaMux?
Deixa eu clicar na nova aba aqui.
Eu estou na parte aqui do gethug, do GorillaMux, tá?
Então, GorillaMux é um módulo de Go, tá?
E esse módulo aqui é para... tem dizendo aqui sobre o que é.
A ajuda a você fazer as rotas, né?
Você tem um servidor web de Go.
Para definição...
Puteador, HTTP, Zipoadjunt, Matur, não sei o que.
Então, esse é um módulo de terceiros, né?
Não é WB, até que é padrão.
E você pode usar esse módulo no seu projeto.
Então, nós temos aqui o código fonte, né?
E é...
Está encapsulado nesse repositor de geth e está hospedado no gethug.
Então, esse é um módulo, tá?
E o módulo pode ter vários pacotes.
Nesse caso aqui do Mux, ele é bem simples.
Eu acho que só tem um pacote.
Se você ver no código fonte aqui, por exemplo, mox.go,
e olha na linha package, né?
Que tem a Java package.
Tem o pacote mox.
E se eu olhar em outro route, mox.go, também pacote mox.
Então, esse módulo é bem simples, por isso, parece que só tem um pacote chamado mox,
que é o mesmo nome do caminho desse módulo.
Mas pode ter vários pacotes.
A gente vai ver no outro exemplo ali.
Então, o que define um repositório como um projeto de Go?
O arquivo go.mode, tá?
Tem que ter esse arquivo go.mode.
O arquivo go.mode, você tem a palavra-chave-módulo,
que vai definir o caminho desse módulo.
Normalmente, vai ser o site de hospedagem,
barra o caminho do repositório.
Nesse caso, get-file.com.bar-gurilla-mox,
que corresponde ao RL aqui em cima, se você ver no navegador.
Tem também a linha pra você definir a versão mínima do Go.
Nesse caso, esse módulo vai funcionar com a versão 1.2 e acima.
Do Go.
Tem também outras linhas que definem as dependências
se o projeto tiver dependência.
Mas como esse módulo de Go.mode, que é bem simples,
ele não depende em nenhum outro projeto de terceiros.
Então, esse é o exemplo bem simples de um módulo de Go.
E pra poder usar isso, é só dar um importe
pra ver esse caminho em um string lá na hora de importe.
Agora, vamos olhar outro exemplo aqui.
Eu vou em outro repositório do Go Ethereum.
Na Go Ethereum, implementação do protocolo de Ethereum
na linguagem Go.
Cryptomoeda, esse negócio.
Então, Go Ethereum aqui, você nota que já tem
muito mais arquivos do que o Go.mux.
Esse olhar aqui, por exemplo,
Core, Blockchain, esse pacote chamado Core.
Package Core, já temos um pacote chamado Core.
Vamos olhar em outro aqui, deixou lá,
pasta GraphQL.
Já vê o package GraphQL, pacote GraphQL.
Então, já tem dois pacotes diferentes no mesmo módulo.
Como eu disse antes, o módulo de Go,
que por si só é mais ou menos um repositório,
pode ter vários pacotes, tem um coletano de pacotes.
E note também que o nome do pacote
não precisa ser o nome,
mesmo o nome do módulo em si.
O nome desse módulo é Go Ethereum.
A gente vai ver aqui como definido no GoMod.
Então, vamos lá, GoMod,
arquivo GoMod, define o nome do módulo aqui,
o caminho, que ele avanto com a barra Ethereum,
barra Go Ethereum.
E define na linha 3,
e define na linha 3,
a versão, esse vai funcionar a partir da versão 1.15 do Go.
Note aqui que o módulo Go Ethereum
depende também em vários outros módulos de Go.
Então, ele define na linha 5 aqui,
chama Require, né?
Abre parênteses aqui, depois de espaço,
e a lista cada um,
lixo de dependências cada um em uma linha.
E não se esqueça de fechar com fecha parêntese no final.
Então, vamos ver a primeira linha aqui.
Ele depende do pacote, gethub.com.barragem, barragem, pipeline Go.
E espaço, a versão,
tenta mesmo comentar aqui que esse negócio aqui,
significa que esse módulo,
módulo é uma dependência indireta, isso é.
Quando você depende de uma outra biblioteca,
ou outro projeto,
essa é uma dependência direta.
Mas se aquele projeto em que você depende,
também depende em outro projeto,
aquele outro projeto é uma dependência indireta,
porque você não referencia ele diretamente.
Isto é, é uma dependência da sua dependência.
Então, às vezes, o Go precisa também incluir
a dependência indireta no seu GoMod.
Então, às vezes vai aparecer esse negócio aqui.
Então, isso indica que esse aqui
não é uma dependência direta,
é indireta, mas,
por alguma razão,
tivemos que incluir no seu GoMod.
Então, prosseguindo aqui,
o próximo depende também do módulo
Azure Storage, lobby Go,
que está nos casos de pedaços de gethub,
nessa conta, Azure.
E a versão especificada aqui,
espaço, versão V0.7.0.
Note que a versão especificada
segue um padrão chamado
Semantic Virginie, sem V,
tá?
Vessionamento semmático.
Por isso que é sempre o mesmo padrão de 3
números separados por um ponto.
No número mais à esquerda,
significa a versão maior, major.
No número do meio, é a versão menor, minor.
E o número mais à direita,
é a versão de patch, né?
Que é feita quando você conserta bugs.
Então, a versão de patch
mais à direita quando você conserta o bug,
você incrementa.
Se você adicionar alguma nova
funcionalidade no programa,
mas que não quebre a compatibilidade,
é uma versão menor que a incrementada.
Se você adicionar alguma coisa que
quebra a compatibilidade com a versão anterior,
tem que incrementar a versão maior,
que é o número mais à esquerda,
e zerar todos os números do meio e da direita.
Tá?
Então é isso.
Então, você note que a maioria dessas dependências
está hospedadas no GitHub.com,
mas tem também algumas que estão em outros
sites, né?
Golang.org, barra, x, barra, crypto.
Golpkg.in, barra, native, barra,
n5.v2.
E assim por diante.
Norte que tem também a...
é possível também especificar
a versão aqui no nome
do caminho final do pacote.
E depois,
certas versões aqui
têm esse número meio esquisito, porque
é o que se chama
piseu do versão que foi
adicionada pelo Gol.
Talvez não tenha esse
golang.org, barra, x, barra, time.
Ele não tenha especificado
uma tag de versão corretamente no seu repositor,
ou algo aconteceu que ele não pôde
identificar que versão é, então Golang
criou essas piseu do versão.
Tá bom?
Então é isso, né?
Então note que
para você ter um... definir
um...
Ah, eu também esqueci de uma coisa aqui.
Quando você tem várias dependências,
vai também ser criado o arquivo
Gol.sum.
Esse Gol.sum é um arquivo de que vai...
vai mostrar que vai incluir
todas as versões dos
módulos que foram usados no seu projeto.
Isso é para poder identificar
quando você
baixar o repositor e
obter as dependências e compilar
quando ele fizer isso tudo, que ele vai sempre usar
a mesma versão que as outras pessoas
usaram, né?
Então esse arquivo também é parte
do repositor e você deve
checar na sua versão de...
controle de versão, caso o Get.
Fazer o check-out, né?
É, então ele mostra várias versões
também do...
mesmo pacote, isso é normal.
Aí mostra esse check.sum,
que ele check os conteúdos, né?
Para ver se não tem
alguma mudança.
Sei lá se vai ver
a versão que você usou,
alguma mudança foi feita no código,
alguma coisa aconteceu, então pode dar problema.
Ou você estava...
Você estava usando esse código dessa maneira
e de repente mudou o conteúdo,
aí vai dar problema, né?
Para aquela versão. Então ele tem
esses check-sums aqui que ele vai
identificar e tal e tem as versões
e por diante.
Então esse que você...
É, também chamar de
lockfire, por exemplo,
você já usou o NPM
com JavaScript,
packagelock.json, similar, né?
Esses tipos de arquivos.
Então, para concluir,
você note que
pacote de terceiros,
módulos, né? De terceiros,
que o módulo pode ter
vários pacotes e o módulo
é hospedado em um repositório
e pode ser qualquer site.
Você note que tem uma descentralização
no gênese amete
de pacotes do Go.
Não tem, assim,
em geral, não tem uma
central aonde
você chama para obter
os pacotes, como por exemplo
no caso de
NPM no JavaScript, que você dá
o NPM em install, ele vai
obter os pacotes da central
do site do NPM.
Não é bem assim no Go. No Go
é mais descentralizado, né?
Então você pode
só... Qualquer
um pode definir um módulo de Go.
Basta ter
algum lugar, né? Alguns sites, como
GitHub.com
e você cria um repositório
e você
tem um arquivo Go.mode
e basta você ter aquele caminho, né?
É, normalmente, GitHub.com
barra o
nome da conta, barra
o nome do repositório
e aquele caminho que você define
no seu Go.mode
e
você usa aquele caminho
nos seus impostos do seu próprio
projeto. E o Go
vai automaticamente
procurar
por aquele repositório
e vai baixar e vai incluir
no seu projeto, né?
E é...
E no Go, quando você
compila, ele já compila tudo
no
mesmo executável,
ele vai botar todas as dependências lá,
incluir todas as dependências.
Não tem esse negócio de
por exemplo, você
vai... Você tem uma
biblioteca que é escrita,
que já está instalada no seu sistema
e você vai
de alguma maneira linkar para poder
usar o
código compilado da biblioteca que está em outro lugar.
Não é assim, ele já inclui
todas as dependências do programa
e o Go depende, ele já inclui
no seu executável.
Isso também significa se você tiver dois
programas
diferentes que incluem
a mesma dependência, cada
programa vai ter sua própria
vamos se dizer
própria conteúdo
com
a questão compilada daquele
módulo de terceiros, né? Então...
Termo de espaço
seria ocupar o mesmo
espaço dobrado.
Essas coisas sim, mas
isso para um negócio
funcionar sem problemas, né?
De alguma
maneira, então, para concluir é só isso.
A gente aprendeu
tem a
biblioteca padão do Go
e tem pacotes terceiros
e qualquer pessoa pode
criar, só criar o repositor.
Tem aquele arquivo Go
Mod, né?
Define
o caminho do módulo, versão
do Go e as dependências
com Require
e você tiver várias dependências
ele vai criar também o Go.sum
que também deve ser incluído
no seu repositor
e vai verificar lá
e
deixar tudo se assim
alguma outra pessoa baixar o repositor
do seu projeto, ele vai instalar a mesma
versão que os outros
desenvolvedores.
Tá bom? Então, por essa aula
é só e eu te vejo na próxima.


0021-01 Módulos de Golang / Go: Como São Definidos

Como Criar um Modulo Biblioteca de Golang (go mod init) para Analisar Consulta Query String

# Resumo da Aula sobre Módulos em Go

Nesta aula, o instrutor ensina como definir um projeto em Go como um módulo, criando uma biblioteca que pode ser importada por outros projetos. A biblioteca em questão incluirá uma função para analisar uma *query string* de uma URL.

## Objetivos da Aula

- Configurar um projeto Go como módulo.
- Criar uma função para analisar *query strings*.
- Explicar a estrutura do arquivo `go.mod`.

## Passos Realizados

1. **Estrutura do Projeto**:
   - O instrutor cria um diretório chamado `Go-modulo-biblioteca` e um arquivo `analisador.go`.
  
2. **Inicialização do Módulo**:
   - O comando `go mod init` é utilizado para iniciar um novo módulo, fornecendo o caminho do repositório no GitHub (exemplo: `github.com/NVKModutech/GoModuloBibliotech`).

3. **Criação do Arquivo `go.mod`**:
   - Um arquivo `go.mod` é criado, contendo informações sobre o módulo e a versão do Go utilizada (1.16.5).
  
4. **Implementação da Função `Analisar`**:
   - A função `Analisar` é definida para converter uma *query string* em um mapa de pares chave-valor.
   - O instrutor explica a importância de que a função seja exportada (primeira letra maiúscula).

5. **Processamento da Query String**:
   - A função usa métodos como `strings.Split` para dividir a *query string* em pares e, em seguida, em chave-valor.

6. **Testando a Função**:
   - As operações realizadas são testadas para garantir que a implementação funcione conforme o esperado.

7. **Preparação para Hospedagem**:
   - O instrutor menciona que a biblioteca deve ser hospedada em um repositório, como o GitHub, para que possa ser utilizada por outros projetos.

## Conclusão

A aula conclui que agora o diretório é um projeto Go com uma biblioteca pronta para ser importada, e que a parte de hospedagem da biblioteca será abordada na próxima aula.

--- 

**Nota**: Este resumo oferece uma visão geral dos principais tópicos e passos da aula sobre como trabalhar com módulos em Go.

Lá pessoal, nesta aula eu vou te ensinar como definir o projeto de Go como módulo.
Então vai ser assim.
Vamos supor que a gente vai ter esse projeto e vai ser como se fosse uma biblioteca.
E essa biblioteca seria importada por outros projetos de Go.
No exemplo que eu vou dar, eu vou fazer uma função para analisar uma query string,
analisador de consulta.
Sabe quando você tem a URL e tem aquela parte quando você tem o final de interrogação,
seguido de pares de chave e valor separado por sinal de igual e cada pares separado por um ampersand.
Então esse vai ser a função que a gente vai colocar nessa biblioteca e outros projetos irão consumir essa biblioteca.
Tá certo?
Então vamos começar aqui.
Aqui eu tenho no meu terminal, eu já criou a pasta chamada Go,
traço módulo, traço biblioteca.
E eu tenho um arquivo chamado analisador.go que eu criei.
Eu gostaria de tornar esse diretório um projeto de Go.
Para poder fazer isso, eu vou rodar o comando de iniciar um projeto, um módulo.
Isso é parecido como se você vendo JavaScript, NPM, é o NPM init,
sabe aqueles comandos de criar um arquivo de projeto, NPM init, yeslint init, assim por diante.
Tá bom?
Antes disso, queria te dizer que a minha versão do Go é 1.16.5,
pode ser que esse comportamento das coisas que eu faço dos comandos do terminal seja diferente de versões anteriores.
Então esse detalhe.
Pronto, então vamos dizer Go, mod, esse é o comando que vai ser das coisas relacionadas ao módulo init.
E agora temos que dizer o caminho desse módulo, né?
Como se fosse uma espécie de nome ao módulo.
O lance é que no Go os módulos são armazenados em repositórios, por exemplo, repositório de Git.
Então tem vários sites que você pode hospedar.
Um site muito popular para hospedar repositórios é o GitHub.com.
Então nesse exemplo, eu já sei que eu vou criar um repositório e vou armazenar no site GitHub.com.
Então eu vou incluir no caminho o caminho para o meu repositório, GitHub.com.
Então eu vou dizer GitHub.com, o barro, o nome da conta, o usuário, a organização, qualquer coisa.
No meu caso eu vou dizer NVKModutech, barro, o nome do repositório.
Eu vou dizer que é o nome GoModulo, bibliotech.
É claro que não precisa ter isso criado naquele site ainda, né?
A gente só precisa de algum identificador para que o comando GoMod possa incluir no arquivo que ele vai gerar.
Então GoMod, init, caminho, seu módulo.
Normalmente o site hospeda o seu nome de conta, barro, o nome do repositório.
Então fala aqui Go, criando novo arquivo Go.mode, módulo, GitHub.com, barro, NVKModutech, barro, Go, módulo, bibliotech.
Vamos dar o LS aqui, nós temos agora um novo arquivo chamado Go.mode.
Vou aqui no meu editor de texto, no background.
Eu estou usando o VJStory Code, desse vídeo, VSCode.
Clico no arquivo Go.mode, você note que a primeira linha aparece, palavra module, indica o módulo, espaço e o caminho, né?
Eu tinha escrevido, escrito no terminal.
Na linha 3 eu tenho a definição da versão do Go, Go, espaço 1.16, porque essa é a minha versão instalada.
E ele espera que minha biblioteca, se for incluído em outros projetos, que a versão seja no mínimo 1.16.
Note que o arquivo é bem simples, porque não tem nenhuma outra dependência.
Normalmente projetos têm várias dependências.
E essas vão aparecer aqui nesse arquivo também, Go.mode, na parte de requerer, require.
Como isso é uma biblioteca que não tem nenhuma dependência, não vai aparecer aqui.
Mas quando a gente for lá no projeto que vai consumir essa biblioteca, a gente vai ter no Go.mode, daquele projeto, a inclusão do caminho para essa biblioteca aqui.
Nesse caso seria o nome, o caminho aqui definido na linha 1.
Tudo certo? Agora, tornamos esse diretor em um projeto de Go, com a criação do arquivo Go.mode.
Agora vamos clicar aqui nesse arquivo que eu criei chamado analisador.go.
Então vou te explicar qual é a função aqui.
Então esse pacote vai ser usado para poder converter essa string aqui, com a query string de um URL.
Se você já viu no seu navegador, na barra de endereço, às vezes tem no final o sinal de interrogação,
seguido desses pares, chave igual valor, separado pelo ampersand.
Então é chamado search ou query string.
Se for traduzir, sei lá, chama string de consulta.
Então esse analisador vai ser para fazer o processo de passe.
Então eu vou tornar uma string em um mapa de string, como índice indexador e valor string.
Aqui busca, ordem e os valores.
Cada primeiro k é busca igual termo.
Significa que a chave será busca e o valor será termo.
No próximo par, ordem igual a 10, ordem será a chave e o valor será a 10.
A busca seria a palavra chave que você teria, por exemplo, no site de busca,
ou em qualquer outro site para poder buscar a palavra chave.
Ordem nesse contexto aqui seria descendente.
Se fosse letra, seria que começasse a duzer e termina no ar.
O nome da função que eu queria é analisar.
Leva como parâmetro a query string e a gente vai retornar um mapa de string.
O nome da função que é importante, a primeira letra, está maiúsculo.
Se fosse minúsculo, ninguém de fora poderia usar esse método para poder disponibilizar essa função.
Para outros projetos utilizarem quando importar, temos que exportar a função.
Basta tornar a primeira letra maiúsculo, caso a maiúsculo.
Agora a função analisar foi exportada.
Vamos lá.
Vamos ver o que fazer.
A primeira característica, não importa, sempre será a final de interrogação,
seguido de várias coisas separadas pelo OMPC,
então a gente pode dar o split nessa string, depois de trair todos depois do primeiro.
Basta, deixa eu ver essa parte aqui.
Quero te mostrar uma coisa.
Quero a query string.
Quero, na verdade, dar a substring.
Ele é ele sim e isso traina de muita build.
Vamos lá ver.
Aqui.
Vamos colocar a variável aqui para fazer o seguinte.
Vamos fazer o seguinte.
Pares, vai ser igual a que esses pares serão
Rage Strings, então vamos colocar slice aqui de string.
Eu vou assim.
Do primeiro adiante deixa eu só ver se está correto.
Eu vou ir aqui no navegador e no playground, Play, Roland.org
Só para te mostrar isso.
Eu disse Query string, só como exemplo, vou buscar igual a termo e
ordem é S, pa, Query string.
Se eu dar o println para o string, a gente espera que como é
se eu disser um, dois pontos, peixe a coxete, ele tira o primeiro
caractere e extrai do segundo em diante seguido.
Perto está aqui para demonstrar que funciona.
E com isso a gente vai dar o split, mais o split vem da onde do strings.
Eu referenciar o modo strings, tem a função split.
Faço o primeiro argumento que é string, segundo será o separador, que nesse
caso é Whamper and abre aspas, %feature parent.
Se quiser tentar no navegador no playground, Play, Roland.org
Play aqui strings.split, %
Deixa eu clicar nesse import para ele poder auto importar.
Note que agora tem uma...
Ele torna slice, eu acho.
Botar o mouse em cima do split, retorna uma slice de strings,
está correto.
Agora, esses são os pares, agora a gente vai ter que ir para cada par,
temos que dividir de novo, mas o separador é o igual.
Vamos lá.
Black.
Dao for loop, Ui.
Igual a zero.
Ui é menor que a length pares e mais mais.
Ali não foi...
Deixa eu ver o que está dizendo aqui.
Play, vou usar os dois pontos igual aqui.
Aí vai certo, agora vamos pegar primeiro a chave,
vai ser uma string, vai ser pares, abre crochet e...
A verdade eu tenho que dividir primeiro.
Deixa eu dividir aqui pares, crochet e...
Vamos dar o split de novo, strings.split.
O separador agora vai ser igual.
Isso vai dar em duas, não é?
Vamos deixar eu ver...
Vamos dizer va, chave valor.
Vai ser partida de string igual.
Aí pega chave valor, sub zero vai ser a chave e vai valor string,
chave valor sub um.
Então a gente já tem a chave, tem o valor, agora vamos criar um...
Um mapa aqui, então eu vou dizer o...
Fala...
O resultado, o hash map.
Vou falar mapa.
O tipo de...
Vai mapa, vai ser igual a um map de string para string e não tem nada.
Então aqui mapa na chave vai ser igual o valor dentro do loop.
E com isso eu vou dar o return do mapa.
A declare...
O que que tá? A declare, fang.
Eu vou dar porque eu botei do lado errado.
O tipo da variável é do lado direito do nome da variável.
É devido a costume de outras linguagens em que a gente escreve o tipo antes.
Desculpe por isso.
Com isso a gente pode testar isso, eu copio esse negócio para o playground só para te mostrar.
Eu vou definir com...
O que pode ser grande mesmo?
Deixa eu dar aqui o...
A gente já lene, vou falar...
Analisar...
Query string...
Já que tem um map, busca termo, ordem 10.
Então só no direitinho.
Eu tento referenciar isso aqui.
FMT, print elenico, analisar query string, salve a busca.
Eu espero ver termo.
Correto, se eu dar ordem eu espero ver 10.
Correto.
Então nossa implementação tá correta, voltando ao editor de texto aqui.
Pronto.
Temos o arquivo já com a implementação da função.
Tá no pacote chamado analisador.
Depende da biblioteca padrão strings.
Mas não precisa pôr no mod que não é de precer a pessoa externa.
Agora vamos para poder usar importar essa biblioteca de outro projeto, que é o projeto consumidor.
A gente vai ter que primeiro hospedar essa biblioteca nossa no caminho que tinha dito do comod.
Nesse caso, gator.com.br, NVK, Mundutech, mas vou trazer o modo, traça biblioteca.
Isso que eu vou fazer na próxima aula, tá certo?
Então até lá.


0021-02 Como Criar um Modulo Biblioteca de Golang (go mod init) para Analisar Consulta Query String

Publicação de Módulo de Golang no GitHub e Import de Dependência de Terceiros

# Resumo do Transcript

O vídeo tutorial mostra o processo de hospedagem de um módulo em Go no GitHub. O apresentador explica passo a passo como criar um repositório e fazer upload do código. A seguir, a síntese dos principais pontos abordados:

## Criar um Repositório no GitHub

1. **Acessar GitHub**: O apresentador entra no GitHub e cria um novo repositório chamado `nbkmoodotec-gomodulebiotec`, optando por mantê-lo público.
2. **Configurar Repositório Local**:
   - No terminal, navega até o diretório do projeto.
   - Inicializa um repositório Git com `git init`.
   - Adiciona o repositório remoto usando `git remote add origin <URL do repositório>`.

## Fazer o Upload do Código

3. **Adicionar Código**:
   - Executa os comandos `git status`, `git add .`, `git commit -m "mensagem de commit inicial"` para preparar e enviar seu código.
   - Se encontrar problemas de autenticação, ajusta a configuração do repositório remoto para usar HTTPS em vez de SSH.

4. **Adicionar Chave SSH** (se necessário):
   - O apresentador gera uma chave SSH e adiciona ao GitHub nas configurações de SSH.

5. **Fazendo o Push**:
   - Após adicionar a chave, realiza o comando `git push -u origin master`, completando o envio do código.

## Consumir o Módulo em Outro Projeto

6. **Criar um Projeto Consumidor**:
   - O apresentador muda para a pasta de um novo projeto chamado `gomodulo consumidor` e abre um editor de texto.
   - Configura o import do módulo no código, referenciando o caminho do repositório GitHub.
   
7. **Gerar o Go Module**:
   - Inicializa o módulo com `go mod init <caminho do módulo>` para o consumidor.

8. **Adicionar Dependências**:
   - Usa o comando `go get` para adicionar a biblioteca ao projeto consumidor.

## Problemas e Resoluções

9. **Erro de Versão**: O apresentador encontra problemas com o comando `go get`, que mostra um erro de "mod provides package". Ele analisa o erro e decide verificar se as tags foram criadas corretamente no repositório do módulo biblioteca.
10. **Criação de Tag**: Ele explica que é preciso criar uma versão fatia (tag) para garantir que o `go get` funcione corretamente.

## Conclusão

O vídeo conclui com a necessidade de resolver os problemas de versão. O apresentador pausar para revisar os comandos relacionados à configuração do módulo e a adição de tags.

Olá pessoal estamos de volta vamos continuar vamos hospedar esse módulo de go que nós criamos
Eu vou no meu navegador agora e vou lá para o github.com já loguei na minha conta aqui
Eu cliquei nesse botão demais e aqui na barra no header na topa direita eu cliquei new repository novo
repositor e aqui eu vou criar no barra nbkmoodotec e vou dizer o nome que a gente
vai ter disponível no github.com e aqui no github.com eu vou colocar o nome do meu repository
Eu vou deixar ele publico porque para outros projetos importarem o código aqui vai ser aberto
Eu vou clicar criar repository.
Pronto agora o repositório está em branco eu preciso enviar o meu código da minha máquina para o servidor do github
Para poder fazer isso é só você dá o adicionar remote com essa endereça aqui
Então vamos lá eu vou no terminal
Eu estou na minha parte do meu projeto da biblioteca eu já tenho o github instalado
Eu vejo a versão aqui que eu tenho a versão 2.251
Para poder eu hospedar no github eu preciso iniciar esse diretório
Iniciar o github então vou falar githinit ele criou a pasta
githinit desculpa pasta.gith no diretório aqui então
Github remote traço ver não tem nada vou falar github remote add origin e aquele direto que você copiou do github
Eu já sei de qual então vai ser github.com 2 pontos nbkmoodotec-gomodulebiotec
É fácil de lembrar sempre githa-github.com 2 pontos o nome da conta barro o nome do repositor
Agora se você dá a github remote traço ver parece que ord vai ser associado a essa endereça
Profete e eu vou puxar agora se eu falar github pux traço o origin ah eu esqueci de dar o comete inicial desculpa
Então deixa eu dar o gith status aqui eu vou dar o gith add tudo no diretório presente que eu sei que só tem 2 arquivos
Eu vou dar a gith comete traço o nm para mensagem comete inicial
Pronto agora eu já tenho o meu comete inicial eu vou dar a gith push ord traço ord master master o nome do meu branch
Ah o problema é que eu tenho que adicionar a minha chave então para essa sete
Então deixa eu...
Esse vídeo não é de adicionar a chave essa sete então vou usar o http s em vez disso
Deixa eu mudar a gith remote
Sato url origin
Esse aqui
Get push.u origin master
Também falhou acho que o passo do...
Autenticação
Ok então
Espera aí que eu vou adicionar a minha chave aqui
Então deixa eu reverter isso
Então getremote traço v
Eu vou botar de novo getremote set url
Opa getremote set url origin
Get help.com, response
Camundo tech bago, módulo, bbloteca.get
Então deixa eu ajustar as minhas...
...táveis aqui
Só um minuto certo eu vou abrir meu terminal
Eu vou na pasta direitora pessoal.ssh
Eu tenho que gerar a minha chave ssh-gen
Ssh-gen
Módulo
Ssh-gen
Ssh-gen
Então
Certo agora eu tenho uma arquiva aqui
Direitora pessoal
id underscore rsa.pub
Que eu vou pegar isso
E vou lá no gethub
Se você for no settings ssh-gen
Você pode adicionar a sua chave lá
Para ter que autorizar
Você terá da ssh-procedor do gethub
Só um minuto estou adicionando a minha chave
ssh-gpgx
Nova ssh-g
Eu posso na...
Ssh-gpgx
Ssh-gpgx
Pronto deixa eu voltar o meu terminal aqui
E vou dar gethub
Traço o wordmaster
Agora funcionou
Eu vou
Iniciar a página aqui
reload
Atualizar
Pronto então apareceu aqui
Eu já tenho hospedado o meu repositor
Tem uma arquiva aqui gomod
Um analisador
Certo
E com isso já hospedado é hora da gente
estar olhado no lado do pacote consumidor
Vou fazer o seguinte
Eu vou dar cd para outra pasta
chamado gomodulo consumidor
E aqui eu vou abrir o meu editor de texto
Feijos tutorial code
Tem um arquivo que eu criei em memo em portugou
E vai consumir o gomodulo biblioteca que a gente criou
Então eu vou fazer o seguinte
Eu vou dar um import daqui
Agora esse import
Você vai referenciar o caminho do módulo
que foi definido no gomodulo
Que também corresponde ao caminho do gethub
Então o gethub.com barra
O nome da conta
Meu caso é nvkmoditec
Barro nome do repositor
Traço módulo, traço biblioteca
E você pode dizer
Aqui o nome do pacote analisador
E aqui você pode usar analisador.
E o que seria analisar o query string
Pode dar fmt
Na verdade vai ser um map
Aqui vai ser o query
Query map
Vai ser esse tipo
Igual
Isso precisa de fmt para encher a ln query map
Claro que tem que portar fmt aqui
Ele separa os bibliotec para a adrão
Adrão de terceiros
Bem legal mas eu não
Tem um gomod aqui
Vamos criar um gomod
Gomod init
E o caminho para o nosso pacote consumidor
Eu também vou usar o gethub
Nesse caso vamos falar
gethub.com barra
nvkmoditec barra
Gomod consumidor
Embora que ainda não exista lava você pode usar
Então gomod fica criado
Para poder adicionar dependência
Posso usar o comando go install
Go install
gethub.com barra
nvkmoditec barra
Gomodiblioteca
Então aqui eu vou adicionar dependência
Cude o caminho do modul s
gethub.com barra
nvkmoditec barra go
Traça o modul, traça o biblioteca
Que é aquela biblioteca que a gente criou
Novkmod provides package
Go gets
Os afalmapels.go gets
Os afalmapels.go gets então
Antes disso eu quero só ver uma coisa
Que acontece no gobuild
mem.go
Também eu dei a mesma coisa
Eu vou falar o goget que eu já volto com o barra nvkmoditec
Cade o modul
biblioteca
Agora tem
gethub.com barra nvkmoditec
ou modul biblioteca
Correto
Ele adicionou essa versão esquisita
Que é a versão
Teu do versão porque
Eu não marquei a tag no positório do
GoModulBiblioteca
E marco as indiretas
Interessante
Certo
Mem
Vamos lá
Dao gobuild
Parece que não está funcionando aqui
Espera aí
Não requer mod provides package
Ok
Deixa eu ver aqui
Deixa eu tirar isso
Análise do
Do
Trai um
Trai um
Trai um
Trai um
Trai um
Trai um
Trai um
Trai um
Trai um
Trai um
Trai um
Trai um
Trai um
Pra chinkada
Trai um
Trai um
Cade o
Laughter
Uma
O que foi
É gostar
Um
такой Duel package
pare a
Então, corre de a sua versão primeiro, depois a gente vê o outro negócio.
Deixa eu te mostrar como corre de a versão.
Está aqui, você nota que não tem nenhum tag.
Ou você pode fazer do terminal, pode fazer do próprio GitHub, create release v0.1.0,
vou publicar, volto para o code, você nota que agora tem um tag aqui,
para essa versão do código, nesse momento tem um tag.
Voltando aqui, se eu dar o goget, GitHub.com.br,
para a NBKMTEC para golmodo Biblioteca at latest.
Deixa eu perceber, fez alguma coisa.
Ainda está aqui, deixa eu tirar isso.
Vou remover o pacote consumidor e vou tentar novamente.
Ainda não.
Vamos dar um pause aqui para eu ver o que está acontecendo e depois a gente volta.
Até mais.


0021-03 Publicação de Módulo de Golang no GitHub e Import de Dependência de Terceiros

Continuação do Modulo Consumidor de Golang (Nome de Import Explicito)

# Resumo do Transcript

## Introdução
O apresentador retorna para demonstrar a solução de problemas relacionados a um projeto em Go.

## Problemas com Versão
- **Versão 0.1.0**: Foi marcada uma tag no GitHub, mas não aparecia ao usar `go get` ou `go install`.
- **Solução**: O apresentador removeu o pacote instalado anteriormente com um comando específico e, após isso, executou `go get` novamente, que identificou corretamente a versão.

## Estrutura de Pastas
- **Pasta Analisador**: O apresentador percebeu que estava tentando acessar uma pasta inexistente e decidiu criar uma pasta chamada `analisador` e colocar o código `analisador.go` dentro dela.
- **Problemas de Auto-Save no VS Code**: Durante as edições, o auto-save do VS Code estava causando problemas, removendo a referência ao módulo em Go.

## Configurações do VS Code
- O apresentador reconsiderou a ativação do auto-save e mencionou que poderia desativá-lo nas opções do VS Code.

## Execução do Código
- O apresentador executou o comando `go build main`, e observou a presença de uma dependência marcada como "Indirect", que causou confusão.
- Ele mencionou a importância de adicionar imports corretamente e garantir que as funções exportadas iniciem com letras maiúsculas.

## Projeto e Repositório
- O projeto foi denominado **Go Mode Biblioteca** e foi inicializado com `go mod init`.
- O repositório no GitHub foi estabelecido, com um commit inicial feito no módulo consumidor.
- O apresentador fez uso dos comandos para adicionar, confirmar e empurrar mudanças para o repositório.

## Considerações Finais
- O apresentador usou comandos de importação e manipulação de dependências, explicando como o código é formatado e executado.
- Conclui a aula, prometendo mais conteúdo nas próximas sessões.

---

## Comandos Usados
- `go mod init <caminho>`
- `go get`
- `go build main`
- `git status`
- `git add`
- `git commit`
- `git push`

## Observações
- Problemas com a estrutura de pastas e a utilização do VS Code devem ser manuseados com cuidado para evitar que o auto-save cause perdas desnecessárias.
- A questão de dependências "Indirect" deve ser investigada mais profundamente.
- O apresentador convida o público a comentar sobre suas dúvidas.

Pessoal, estamos de volta, deixa eu mostrar como é que eu vou fazer os problemas aqui.
Primeiro da versão, antes que tenha o seu do versão, a gente marcou a tag
versão 0.1.0 lá no GitHub, mas não apareceu quando a gente deu o gol get ou gol install de novo.
Então, para acordar disso, eu removi o pacote que tinha sido instalado antes.
Vou mostrar o comando. O meu gol path é o tilda barragou, então eu removi o barra pkg
barramaldbarguerau.com, barra de ubicarmotec, barragou, traço o módulo, traço a biblioteca.
Arrouba a versão lá. Depois de remover esse pacote, eu posso dar o gol get novamente.
Arrouba leiras e ele vai, é corretamente, identificar a versão 0.1.0.
E com isso ele vai acordar o arquivo.
Agora, o próximo problema.
O meu em portugou, ele não está... Eu removi isso.
O problema aqui que eu estava tentando entrar na pasta analisador que não existe.
Em uma maneira de corredir isso, é voltar lá no módulo gol e criar uma pasta chamada analisador
e colocar o código analisador.go dentro da pasta analisador. Isso corrediria o problema.
Eu vou demonstrar já no GitHub.
Outra coisa que eu poderia fazer é, em vez de estar na pasta deixado mesmo de antes,
e aqui removeria a analisador daqui.
O problema que eu tenho é que quando eu aperto para salvar,
ele formato o negócio e remove, o módulo em portas automaticamente.
Aí isso fica num declarário da erro.
Eu teria que remover essa auto para salvar, porque não dá certo não.
Ou talvez, se eu tentar recarregar o meu VS Code, não sei se é por causa disso.
E deixa eu salvar. Agora o negócio funciona.
Então, depois que eu recarreguei o VS Code,
o detector que eu tenho realmente este modo e coloco o analisador aqui e apareceu.
Tá?
Eu acho que não precisaria disso, não sei.
Mas ele sempre saiba porque o meu auto salvar está ativado.
Se eu quis desativar o auto salvar, no meu caso,
eu poderia mudar as minhas opções do VS Code.
Eu deixei assim mesmo.
Acho que isso não parecia qualquer coisa.
Eu acho que coisas indirect, mas acho que está incorreto para falar a verdade.
Eu não acho que é indirect, mas deixa eu remover isso.
Remove e se eu deixar assim e dar o Go Build,
Go Build Main,
Noerco-Remo...
Go Get, Pegue.
Indirect.
Muito estranho, Indirect. Não leve o video.
Parecer.
De qualquer maneira.
Vamos ver...
Go Build Main,
Executamento,
Parece Map, busca Term e order 10.
Tá bom?
Tem o Import, tem o caminho.
Neste caso, ele põe o Waze aqui.
Quando eu auto-salve ele, coloco aqui.
E eu posso referenciar o analisador,
analisar que vem lá do módulo biblioteca.
É, ele adiciona para o Go Mode aqui.
Require, eu não sei porque tem Indirect,
eu acho que não deveria ter.
Algum coisa está estranha.
Mas se você sabe alguma coisa disso, comenta aí nos comentários.
Tá bom? Então vamos revisar tudo que a gente fez.
Criamos um projeto chamado Go Mode Biblioteca.
Tornamos o módulo de Go, Go, Mode, Init,
caminho do módulo, neste caso,
e ele rola ponto com o barra NBK,
muda o tech e barra Go, traz o módulo, traz o biblioteca.
A versão 1.16.
Enviamos o arquivo analisado pelo Go, deixa eu tirar essa parte.
Não precisa.
Definimos a função e exportamos com a primeira letra maiúscula.
Enviamos o código para o GetSub,
está hospedado aqui,
e NBK muda o tech, barra Go,
traz o módulo, traz o biblioteca.
Adicionamos o Anteag aqui para ele poder
detectar na hora de dar o Go install ou o Go Get.
Agora, lá do outro projeto que é o pacote consumidor da dependência,
estamos de novo, Go, Mode, Init,
o caminho que eu defini, Go, Módulo, Consumidor.
Eu ainda não vi a Vivo GitHub, mas
deixa eu fazer agora.
Verdades.
Só para você ver.
O repositorio.
Go, Módulo.
A versão 3.16.
Go, Módulo.
Consumidor.
Cúbico.
Processo ACET, copy isso aqui.
Termina o.
Status, não engage in it.
Status, Add, Go, Mode.
Você pode também adicionar o Go.Sum.
Main.Go.
Status.
Commit, Commit inicial.
GetRemote, AddArgent.
GetPushLastView, Argymaster.
Pareceu aqui.
Correto.
E agora, está aí.
Então, parece o recorde aqui no código.
Você dá o import com o caminho e adicione aqui do lado esquerdo.
Isso apareceu porque deu o meu formatado adicionado,
mas tente sem isso.
Não sei se funciona sem o alias também,
como no caso do FMT.
Aí eu posso chamar no isado a analisar com o car string.
Exemplo, e deu o print, e apareceu lá.
Quando deu o GoBuild,
Main.Go, e executei ponto barra main.
Está bom?
Sim.
É por essa aula só e até a próxima.


0021-04 Continuação do Modulo Consumidor de Golang (Nome de Import Explicito)

Publicação de Nova Versões de um Módulo de Golang e Melhor Maneira para Import

# Resumo da Aula

Na aula, o instrutor apresenta um novo método para trabalhar com o módulo do Google chamado **Modul Biblioteca**. Ele realiza as seguintes etapas:

1. **Criação do Diretório Analisador**:
   - O instrutor cria uma pasta chamada `analisador`, que corresponde ao nome do pacote.
   - Essa pasta pode conter vários arquivos como `analisador.go`, com a mesma declaração de pacote.

2. **Manipulação do Git**:
   - No terminal, ele verifica o status do Git e adiciona a nova pasta `analisador`.
   - Realiza uma série de comandos `git` para mover arquivos e realizar um commit.

3. **Criação e Push de Tags**:
   - O instrutor cria uma nova tag, versão `0.2.0`, e faz um push das tags para o GitHub.
   - Ele repete o processo para a versão `0.3.0`, garantindo que as alterações são refletidas corretamente no repositório.

4. **Modificações no Módulo Consumidor**:
   - Ele modifica o módulo consumidor para utilizar o diretório `analisador` corretamente.
   - O instrutor usa o comando `go get` para atualizar a versão das dependências.

5. **Conclusão**:
   - O instrutor enfatiza que o Go suporta várias versões e que ao usar o `go get`, não há mais a necessidade de sobrescrever o nome do módulo.
   - Ele convida os espectadores a acessarem os repositórios no GitHub e encerra a aula.

---
**Observações Finais**:
- O instrutor agradece aos alunos, pede para deixarem comentários e likes, e se despede até a próxima aula.

Olá pessoal estamos de volta nessa aula vou falar da coisa que eu fiz anteriormente do
Google Modul Biblioteca que eu tinha feito sem criar o diretório analisador, mas nesse
caso nesse vídeo eu vou fazer com o diretório, então em vez do ele esse aqui, então deixa
eu voltar lá para o modelo biblioteca e criar uma pasta de novo, chamada analisador que tem o
mesmo nome do arquivo do package, então deixa eu te falar, então a pasta, o nome da pasta vai ser
o idente com o nome do pacote que chama analisador, agora o pacote analisador pode ter vários arquivos
pode ter analisador.go, pode ter outro arquivo.go e nesse outro também vai aparecer o mesmo pacote
e pode ter outra função, sei lá, outra, retornar outra, stream, não faz nada, então temos dentro da
pasta analisador, todos os arquivos aqui serão referenciados, package analisador, só para separar as
então com isso eu vou aqui no terminal do modo biblioteca, vou dar o get status, eu vou adicionar
pasta analisador, get status agora vai ter esses dois novos arquivos, eu vou falar mover arquivos para pasta analisador
e vou dar o get push, vou ensinar como adicionar a nova tag para a nova versão, certo?
então eu vou criar a versão zero, deixa eu dar o get path para pegar as tags, você não acha que eu pegue a tag 0 1 2 0 1 0
e eu quero fazer a nova versão zero, zero através da linha de comando, vou dar a get tag, traço a v 0.2.0
e vou falar release v 0.2.0, sai, sim, ok, agora eu tenho a outra tag, agora eu tenho que falar push, get push, traço traço tags
para ele mandar a tag lá para o get hub, agora se eu voltar lá para o get hub, o get hub module bbliotec
eu tenho agora dois tags, tem a v 0 2 0, agora temos o analisador pasta e eu tinha esquecido de deletar o analisador.go, ou não, deixa eu deletar isso, desculpa
get add analisador, vou ver arquivo, analisador e esqueci
agora vou fazer outra tag, ok, vou traço a v 0.3.0, traço a v 0.3.0, sai, ok, get push
agora vou dar a get push, para empurrar o master e get push, traço as tags para empurrar as tags, para mandar as tags
agora voltando o get hub, reload, tem três tags, tem v 0 3 0 e o analisador, o arquivo não está mais no diretório, raiz
pronto, legal, voltando aqui para o módulo consumidor
eu quero modificar esse negócio e não usar mais, desculpa, essa estava errada, não usar mais esses, mas na verdade usar a barra analisador, se eu quero fazer
vou ver se go get vai pegar o que eu quero ou não
vou ver se vou colocar o get at v 0 3 0, agora ele baixou, vou botar a rouba v 0 3 0.3 0, atualizo aqui, na hora de que ele remover o negócio de indirect, eu achava que estava errada e realmente remover o negócio
pronto, e com isso vou dar o main.go, não tem mais aquele outslave de adicionar o analisador, porque está corretamente no diretório, se eu dar o go build, main.go, e dar.main funciona
foi isso, na parte do módulo da teka, tenho que criar uma pasta, o nome do pacote e pode ser vários múltiplos arquivos, refeirando o package, o mesmo nome da pasta na primeira linha
e com isso vou voltar para o pacote, consumidor, e o go get é a rouba, com a rouba da versão 0 3 0, ele certou aqui e remover o negócio de indirect, não é indirect
a note que o go são adiciona várias versões, desde aquela sudoversão até 0 1 0 0 3 0, isso é normal
e é isso, não tem mais aquele override do name, isso que eu queria originalmente, tá bom?
então, vou dar o commit para vocês terem, acesse, atualizar o módulo, e vou lá
vocês podem acessar isso no get hub, do go módulo consumidor e do go módulo biblioteca, certo?
então por essa aula é só, muito obrigado por assistir, deixe seu like, deixe seu comentário e muito obrigado pessoal de anciia e até a próxima


0021-05 Publicação de Nova Versões de um Módulo de Golang e Melhor Maneira para Import

PKG GO DEV: Site Diretório Indice de Módulos de Golang

# Aula de Golang: Explorando o pkg.go.dev

Olá pessoal! Nesta aula, abordamos o site [pkg.go.dev](https://pkg.go.dev), um índice de módulos de Golang. Este site é uma ferramenta excelente para explorar vários módulos disponíveis para a linguagem Go.

## O que é o pkg.go.dev?

- **Índice Centralizado**: Apesar dos módulos de Go serem distribuídos de maneira descentralizada, o pkg.go.dev funciona como um diretório onde é possível pesquisar pacotes existentes.
  
## Como Usar?

1. **Busca por Módulos**: Você pode buscar por pacotes, como por exemplo `http`. O site fornece informações como:
   - Versão do pacote
   - Data de publicação
   - Licença
   - Dependências e imports

2. **Informações Adicionais**:
   - O módulo `http`, por exemplo, possui 653.401 importadores.
   - Você pode ver quais módulos dependem dele através da opção "imported by".

3. **Exemplo de Busca**:
   - Ao procurar por "Hugo" ou "Rei", o site mostrará detalhes da versão, licença e quais módulos são importados.

4. **Acesso ao Código**:
   - O site também fornece acesso ao repositório, podendo verificar o conteúdo do arquivo GoMod no GitHub.

## Documentação

- Existe também a opção de acessar documentação através do GoDoc. Clicando na documentação de um módulo, você pode encontrar informações detalhadas como:
  - Visão geral
  - Tipos
  - Constantes
  - Variáveis

## Conclusão

O pkg.go.dev é uma ferramenta valiosa para pesquisadores e desenvolvedores em Golang, facilitando a exploração de pacotes e documentação. Até a próxima aula!

Olá pessoal, estamos de volta com mais uma aula de Golang.
Nesta aula eu gostaria de falar desse site pkg.go.dev que é um índice de módulos de
Gol, bem legal esse site para você explorar vários módulos que existem.
Então, no mundo de Gol os módulos são distribuídos de maneira descentralizada,
mas tem esse site aqui que quer como se fosse uma central ou índice que você
pode pesquisar os pacotes que existem para a linguagem.
Esse website é o pkg.go.dev.
Por exemplo, aqui no site você pode fazer uma busca, por exemplo, eu busco http.
Claro, ele mostra o http aqui, tem a versão.
Então, ele começa aqui, descubra pacotes, esse aqui pertence à biblioteca padrão,
não é de terceiro, está dentro de net, está dentro do http, mostra a versão.
Aqui, data de publicação, licença, quantas dependências ou imports ele faz.
Ele mostra que esse módulo http importa a biblioteca padrão esses módulos e
de outros terceiros esses módulos aqui.
E tem também quem que está usando, quem que depende desse módulo.
Se eu clicar importe by, ele mostra que todos esses módulos importam o módulo http.
São muitos, né?
653.401 importadores desse módulo http.
Bem, mas vamos olhar outra coisa aqui, vamos ver, sei lá.
Vou procurar Hugo, ou talvez Rei.
Então, esse aqui, ele mostra aqui a versão, última versão, aplicado, licença a parte 2.
Então, ninguém está importando esse módulo, mas esse módulo importa 13 coisas,
provavelmente a maioria da biblioteca padrão mostra aqui o layame e o repositório onde ele está hospedado.
Tem também, mostra aqui, esse módulo tem o GoMod,
tem que clicar aqui, ele vai lá para o GitHub e mostra o conteúdo.
Tá bom? Então, esse é o site pkg.go.dev, você pesquisa módulos de GoLang.
Embora que GoLang tenha sistema de módulos descentralizado, nós podemos olhar esse site como se fosse um índice ou diretório de pacotes que
a galera do Go Indexal e disponibiliza para você fazer seu pesquisa.
Ah, também tem, acho que documentação, tá?
O GoDoc, se você clicar no documento, ele vai mostrar a documentação do módulo, esse, no caso, não tem nada, mas você olhar em outros pacotes.
Por exemplo, vamos ver esse aqui, documentação, esse já tem várias coisas.
Overview o índice dos tipos e tal e tal, constantes, variáveis, não tem várias coisas.
Aqui os fontes, layame.
Tá bom? Então, por essa aula só e até a próxima.


0021-06 PKG GO DEV: Site Diretório Indice de Módulos de Golang

Módulo com 2 Pacotes, Documentação GO DOC, Publicação e Consumo de Nova Versão

```markdown
## Resumo da Aula

Nesta aula, foi ensinado como adicionar um novo pacote a um módulo Go existente, resultando em um módulo que contém dois pacotes. O foco foi também na documentação usando o formato goDoc.

### Principais Tópicos Abordados

1. **Indexação no pkg.go.dev**:
   - O módulo foi indexado no site `pkg.go.dev`, onde versões anteriores podem ser encontradas.

2. **Estrutura do Módulo**:
   - O módulo possui uma pasta chamada `analisador`, que contém um único pacote chamado `analisador`.
   - Um novo pacote, `console-lidar`, foi criado para consolidar resultados do analisador.

3. **Implementação da Função**:
   - A função `mapa para string` foi criada no pacote `console-lidar`, convertendo um mapa de chaves e valores em uma query string.
   - Exemplo de como utilizar laços `for` para iterar sobre o mapa e construir a string.

4. **Documentação do Código**:
   - Para documentar a função, adiciona-se um comentário acima da assinatura da função.
   - A forma de documentar pacotes também foi explicada.

5. **Publicação do Módulo**:
   - A nova versão do módulo (0.4.0) foi publicada no GitHub.
   - O processo envolveu comandos Git para adicionar e marcar a nova versão.

6. **Uso no Pacote Consumidor**:
   - O pacote consumidor foi atualizado para usar a nova função `mapa para string`.
   - Demonstração da atualização da versão do módulo usando `go get`.

7. **Visualização da Documentação**:
   - A comparação da documentação gerada no Go e no pkg.go.dev foi apresentada.

### Conclusões
- A aula finalizou com a implementação bem-sucedida da função e a verificação da documentação. O instructor incentivou os alunos a interagir, deixar comentários e curtir a aula.

**Obrigado por assistir!**
```


Pessoal estamos de volta com mais uma aula.
Esta aula eu vou te ensinar como adicionar um outro pacote para um módulo já existente.
O módulo terá dois pacotes.
Vamos também aprender a documentar o nosso módulo, os nossos pacotes, na maneira do goDoc.
Antes de começar, gostaria de te mostrar uma coisa legal.
No tema do nosso módulo que a gente fez, o Go traço módulo para a subbiblioteca,
que a gente foi indexado no site do gopkg.go.dev.
Se você buscar, pelas palavras, o NBKMoodutech, que é parte do caminho do módulo,
ele encontrou aquela versão 0.3.0 que nós lançamos anteriormente.
Bem legal, porque é hospedado no gethub.com.
O pkg.go.dev faz uma coletânea, deve ser todos os dias,
procura novos módulos que aparecem no gethub e apareceu o nosso módulo que agora aparece aqui.
Bem legal então.
Então 0.3.0 a última vez publicado nessa data.
E mostra até os imports, que é strings.
Tá bom?
Agora vamos ao tópico do abrir meu editor de texto.
Estou no projeto Go traço módulo para a subbiblioteca.
Lembra que tem a pasta analisador e o nome da pasta corresponde ao nome do pacote.
Nem sempre é assim, né?
Às vezes o nome da pasta é diferente do nome do pacote.
Na hora de importar, tem que usar o nome da pasta,
mas na hora de usar, tem que usar o nome do pacote.
Meu confuso, né?
Mas tem esse detalhe.
Certo? Então temos aqui um pacote só chamado analisador.
Então como o diretório indica que é um só pacote,
todos os arquivos dentro desse diretório por convenção são parte do pacote analisador.
Agora eu gostaria de fazer o seguinte, criar outro pacote diferente de analisador.
Nós temos um módulo que terá dois pacotes.
Lembre que o módulo pode ter não só um, mas vários pacotes.
Basta criar um diretório diferente para cada pacote.
Então eu vou criar uma nova pasta lá em cima.
E vou chamar de console-lidar.
Esse pacote-lidar vai ter um método, uma função,
e irá consolidar o resultado do analisador para poder fazer a operação reversa.
Se você se lembra, nós pegamos o one string na função analisar
e retornamos o mapa indexado por string, cujo valor é string.
Nós queremos fazer a operação aposta.
Então eu vou criar um arquivo chamado console-lidar.go,
vai ser pacote-console-lidar, e vou criar a função, vou chamar mapa para string.
Note que a primeira letra é maiúscula, porque eu quero exportar essa função
para ela ser consumida de fora, por terceiros.
O mapa para string, como o nome já sugere, leva como entrada o mapa de string.
Abre crochet string, fecha crochet.
Cabe com o valor string.
Eu vou dizer isso, mapa, como o nome da variável.
O valor de return será um string, que é o mapa com a solidar e o monstros string.
Está certo?
Vamos fazer implementação aqui.
Primeiro vou fazer uma string para poder armazenar a query string,
da maneira que a gente pega cada chave e valor.
Vou chamar var, str, e vou chamar de query string.
Igual a começa com sinal de interrogação, então já vou iniciar a variável com esse sinal.
Agora vou fazer um loop for chave valor, 2 pontos igual range no mapa.
Vou fazer repetição para cada chave e valor do mapa, foi fornecido como entrada.
Então vou fazer o seguinte, a query string vou associar o valor de existente e vou combinar com a chave igual valor.
Para combinar isso tudo vou usar o s frente f, fmt.sfrontf.
Abre aspas por cento ao b igual para cento ao v, chave, valor.
O valor de cento ao v será substituído pelo valor de chave, cento ao segundo, cento ao v, vai ser o valor de valor.
Se eu salvar meu arquivo ele importa automaticamente.
Legal, eu fiz esse loop, no final vamos retornar a query string já construída.
Mas tem um detalhe, eu não tenho o separador, eu preciso adicionar isso, mas quando adicionar.
Bem, não é no primeiro, porque se você adicionar primeiro vai ficar assim.
Já vi valor, e está errado, então a gente tem que pular o primeiro.
Por isso vou fazer isso, tenho que me lembrar qual é o índice que eu estou.
Então vou começar com fm variavel para índice, e vai índice começa do zero.
E cada vez que eu faço uma repetição, eu aumento o índice mais um.
Agora antes de adicionar chave e valor a string, eu tenho que ver se o índice não for o primeiro.
Eu vou adicionar 1%. Query string igual to query string mais 1%.
Como eu faço essa operação, pego o valor existente com a catena, com o % e atribui a variável mesmo.
Eu posso simplificar isso com o mais igual, o operador mais igual, mesmo maneira aqui embaixo.
O operador mais igual.
Está bom.
Para demonstrar esse uso, vamos fazer o seguinte.
Deixa o e no terminal.
Eu quero testar isso antes de fazer o comito e fazer uma nova versão do módulo.
Eu gostaria de ir no playground, só para testar isso bem rapidinho.
Mapa para string. Preciso de um exemplo.
Mapa map string igual.
Busca igual a 2 fontes.
Termo entre aspas, vígula, abre aspas, ordem, fecha aspas, 2 fontes.
Desse, fecha fecha.
Tem um mapa literal.
Vou chamar o mapa para string, que está dentro do módulo que...
Ah não, não tem módulo ainda. Vou chamar só o mapa para string com o mapa.
Vou dar o fmt.println isso.
Se joga alguma coisa ou não?
Então temos o sinal de interrogação seguido do primeiro par, que é busco igual termo, separado pelo ampersand.
Um ordem igual desce, o segundo par, separado pelo sinal de igual.
Então está certo.
Com a função la lidada, eu vou voltar o meu editor de texto.
Antes de publicar, eu queria te falar sobre a documentação.
Deixa eu ir no terminal de mostrar uma coisa.
Eu falo a Go, espaço doc, espaço consolidar.
Ele me mostra a documentação do pacote consolidar.
Ele diz pacote consolidar, importe, está aqui como importar.
E mostra uma lista de funções.
Nesse caso, consolidar tem uma só função e mostra a assinatura da função com a entrada e a saída.
Isso é bem legal.
Na maneira de você documentar o seu código no Go, é a seguinte.
Você cria uma linha acima da coisa que você quer documentar.
Por exemplo, eu quero documentar a função mapa para string.
Então a linha 5 tem a assinatura da função.
Então na linha anterior, que é nesse caso nova linha 5, eu vou adicionar barra a barra, espaço.
Eu tenho que dizer o mesmo nome da função, mapa para string, e explicar o que é.
Mapa para string, mapeia, consolida, as chaves e valores de um mapa.
E cria um string e com o seguinte formato.
Barra a barra, espaço, espaço.
Estou explicando aqui o sinal de interrogação.
Vou dar, por exemplo, chave igual valor, chave 1 igual valor 1, ampersand, chave 2 igual valor 2.
A ampersand é assim por diante.
Eu vou deixar assim mesmo.
Se você quiser adicionar outro parágrafo, é só criar uma linha em branco entre o primeiro parágrafo e o segundo.
O mapa segue.
O mapa de entrada tem o seguinte formato.
Chave 1, 2 pontos, valor 1, chave 2, expontos, valor 2.
Se eu salvar isso e voltar o meu terminal e falar Godop com solidar, ele devia mostrar.
Muito estranho ver mais coisas.
Talvez eu tenha que dizer consolidar.mapa para string para ter mais informações.
Para ter uma informação específica sobre essa função, eu digo Godop, espaço, doc, espaço, consolidar.mapa para string.
Ele mostra a descrição que eu tinha escrito lá.
Para te ajudar a visualizar melhor o significado da documentação, porque documentar, eu vou do navegador no site do pkg.go.dev.
Se eu clicar em qualquer pacote, por exemplo, da biblioteca padrão FMT, eu tenho essa documentação.
Essa documentação é gerada pelo Godop. Você note que tem um índice e aquele mesmo índice que aparece quando a gente falou Godop.
Se você clicar em uma das funções, ele mostra a descrição. Essa descrição é aquela que você pode ter lá nos seus comentários no código.
Deixa eu te mostrar isso tudo como aparece no código fonte do Go.
Se eu clicar de volta no VJ Studio, por exemplo, no sprintf, se eu clicar com o botão direito, no vscode com a extensão do Go, eu posso ir para a definição.
Ele mostra aqui a definição e tem o comentário de Godop aqui.
O nome da função, a mesma coisa e a descrição.
Vamos ver se é a mesma coisa. Formats e defaults.
Deixa eu copiar sprintf, format, corrente, format.
Vamos olhar que é a mesma coisa. Se eu dar no functions, funções, sprintf.
Você note que esse texto aqui, deixa eu copiar.
Vou lá aqui e corresponde ao mesmo texto do comentário aqui.
Na linha anterior a assinatura da função.
E assim por diante, você pode notar que o código fonte do Go também tem vários comentários.
E eles servem para a geração de documentação através do Go Doc.
Voltando com solidar para o Go, você também pode adicionar uma documentação, comentário para o pacote inteiro.
Para fazer isso, você vai lá na linha anterior a package, que tem a palavra chave package.
Crio a nova linha acima com o comentário.
Barra, barra e escreve package.
Espaço o nome do pacote no meu caso com solidar.
Tem funções para converter um mapa de query string para...
Funções para converter um mapa de chaves e valores para uma query string.
Descionar na linha anterior.
Deixa eu salva isso. Volto na minha terminal Go Doc com solidar.
Já mostra que package com solidar tem funções para converter um mapa de chaves e valores para um query string.
A descrição apareceu aqui.
Então com esse Go Doc já aqui, eu quero publicar uma nova versão do meu modo.
No terminal eu vou dar o Get status, notas que não estão monitoradas.
Vou adicionar Get Add com solidar, que é a nova máscara.
Vou dar o Get Tardenove, vou dar o Get Dip para a stage.
Vou adicionar novo arquivo, o Get Comet, para adicionar pacote com solidar.
Vou dar o Get Push, vou adicionar ou marcar esse commit com uma nova versão 0.4.0.
O Get Tag, se passa o traço A, V, 0.4.0.
Vou chamar o release, o lançamento, V, 0.4.0.
Sai, salva assim, ok.
Get Push, traço traço tags.
Deixa eu ir lá no GitHub.
A nova janela.
O botucon, deixa logo aqui.
Tem um minuto por favor.
Espera aí, tá?
Tá aqui.
Acabamos de publicar a nova versão V, 0.4.0.
Olha o que eu fiz.
Vou dar o Get Push, o Get Push, o Release, o Release.
Vou dar o Get Push, o Release, o Release, o Release.
Está aqui.
Acabamos de publicar a nova versão V, 0.4.0.
Olhando o código, agora tem que consolidar aqui.
Tá?
Então, vamos voltar, agora a gente pode usar isso lá do pacote consumidor.
Se quer demonstrar o uso do pacote consumidor, o Import, tá?
Como vai ser diferente.
Pasta mudar a pasta.
Então, vamos...
Eu volto aqui, termino, vou dar Code, vou abrir o Go, Módulo Consumidor.
No Módulo Consumidor, eu quero fazer a operação reversa na linha 15, nova linha 15.
Eu vou fazer o seguinte.
Eu vou...
Então, eu quero chamar Consolidar, ponto, mapa para stream.
Esse query map que é o resultado da chamada para analisar.
Então, esse resultado vai ser uma string, né?
Aqui, vai query string,
revestida.
Falo é string, igual, tipo string, que vai dar o fmt.println, query string, revestida.
Ele não sabe de onde Consolidar vem, então, só adicionar aqui no Import.
A versão que a gente tem do GoModuloBioTec ainda, 030.
Então, não vai funcionar, acho que a gente vai transicionar o Import.
Mas, espera aí.
Então, no Import, você vai fazer o seguinte, é só adicionar github.com,
barra nbkModuloTec, barra Go, traçoMódulo, traçoBiblioteca, da mesma maneira anterior,
mas em vez de barra analisador, você fala barra.
Consolidar, que é aquele diretório que a gente fez.
Obviamente, vai dar erro porque não tem a nova versão ainda.
Não é aqui, desculpa, estou no lugar errado.
Eu tenho que cd para o GoModulo Consumidor, Go, BuildMemopropagoo.
Então, está adicionando aqui que não tem esse aqui.
Então, deixa eu olhar no GoModulo.
Você pode atualizar o negócio, se eu falar Go,
Barra nbkModuloTec, ou é Get, acho que vai ser GoGet,
GoModulo, Biblioteca, Arroba, V040.
E funciona, eu vou instalar.
Vamos dar um olhado no GoSum, para que vai mudar.
Vou dar um olhado no GoSum, para que vai mudar.
Deixa eu olhar, sim.
Vou dar um olhado no GoSum, para que vai mudar.
E o que é isso?
Deixa eu olhar o erro.
Módulo encontrado, mas não contém pacote.
Vou falar GoGet.
Então, GoGet fez o upgrade.
Eu vou instalar.
Require v040, correto.
Agora vai Go, BuildMemopropagoo.
Conte o barra bem.
A segunda printLn, final de interagência, busca igual termo,
100, ordem igual 10.
Então, tonou direitinho.
Eu quero só dar um olhado aqui de novo no
GoGolModoBiblioteca.
Você olha no site do pkg.gol.dev, ele já pegou a versão 0.4.0
e já detectou que tem o consolidar.
Vou clicar em consolidar.
Documentation, não tem.
Dá o idado.
Vale GoMod, não tem licença, tag, bolo, e a mão vai.
Certo.
Enfim, pareceu aqui, certo?
É isso mesmo.
É visando o que a gente fez.
Criamos um novo pacote chamado Solidar.
O Solidar tem seu próprio direitório no módulo Biblioteca.
No arquivo criamos a função mapa para Swing, que leva como entrada
o mapa que foi gerado pela função do analisador, analisar,
e retorna o one string no formato.
Aprendemos também a fazer comentários na maneira do GoDoc
para documentar o nosso código.
Basta adicionar o comentário na linha anterior, aquela coisa que você quer comentar.
Não se esqueça de copiar o mesmo nome nesse caso da função,
você tem que ter o mesmo nome da função como a primeira palavra do comentário.
O comentário tem que começar com a palavra que corresponde ao nome da coisa que você quer comentar.
Pode também fazer o comentário sobre o pacote em todo, na linha anterior,
ao declaração do package.
Nós publicamos uma nova versão no GitHub e automaticamente
também detectou lá no pkg.go.dev.
Usamos no pacote consumidor.
Nós fizemos o upgrade com o GoGet e o caminho do modo,
ele atualizou e fez o upgrade da versão 030 para 040.
Com isso a gente fez a demonstração da chamada do mapa para a string e funcionou direitinho.
Eu termino aqui fazendo o GoGetStars e atualizar o squad para vocês verem no GitHub.
GoSum em português.
Comentos.
Usamos a função mapa para a string.
Tá bom por essa aula, muito obrigado por assistir, deixa o seu like, deixa também comentar e até a próxima.


0021-07 Módulo com 2 Pacotes, Documentação GO DOC, Publicação e Consumo de Nova Versão

Como o Golang Escolhe que Versão da Dependência Usar (Versões Semânticas e Seleção Mínima)

# Resumo da Aula de Golang: Gerenciamento de Versões de Módulos

Bem-vindo à aula sobre como o Go lida com diferentes versões de um mesmo módulo, abordando dependências indiretas.

## Introdução

- O foco da aula é o gerenciamento de versões semânticas e a escolha de versões de módulos pelo Go.
- Um exemplo prático é apresentado com um consumidor que depende de múltiplos módulos (A, B, C), todos os quais dependem do módulo X, mas com versões diferentes.

## Versões Semânticas (SemVer)

### Formato de Versão
- As versões são numeradas como `vX.Y.Z`, onde:
  - **X**: Versão maior (major)
  - **Y**: Versão menor (minor)
  - **Z**: Versão de patch (patch)

### Significado dos Números
1. **Versão Maior**: Incrementa em mudanças que quebram a compatibilidade.
2. **Versão Menor**: Incrementa ao adicionar novas funcionalidades de forma compatível.
3. **Patch**: Incrementa ao corrigir bugs sem alterar funcionalidades.

### Importância da Compatibilidade
- Mudanças na versão maior quebram a compatibilidade, enquanto mudanças na versão menor ou de patch não quebram.

## Escolha de Versões no Go

### Mínima Seleção de Versão (Minimum Version Selection - MVS)
- O Go escolhe a versão mais recente que atende as dependências dos módulos consumidores (mantendo compatibilidade).
- No exemplo, o Go escolheria a versão 1.8.0 do módulo X, mesmo que os módulos A e B não usem suas funcionalidades adicionais.

### Condição Necessária
- As dependências devem seguir corretamente o padrão SemVer para que a seleção funcione como esperado.

## Demonstração Prática

- O comando `go list -m all` pode ser usado para verificar qual versão está sendo utilizada na construção do consumidor.
- Ao modificar as dependências (excluindo módulos), a versão utilizada mudará conforme a necessidade de cada módulo.

## Conclusão
- O gerenciamento de versões é essencial para garantir que as dependências funcionem corretamente sem quebras.
- O Go faz isso eficientemente através da seleção da versão mínima disponível para cada módulo.

Até a próxima aula!

Bem-vindo a mais uma aula de Golang. Nessa aula eu vou falar de como o Gol lida com versões diferentes do mesmo módulo.
Este módulo vindo como, por exemplo, dependências indiretas através de um módulo que você requere explicitamente.
Eu vou começar explicando versões semânticas e depois disso a gente vai ver como é que o Gol escolhe qual versão do mesmo módulo usar na build final.
Então vamos lá pessoal. Eu tenho esquecido este diagrama. No topo de diagrama tem uma caixa com o texto consumidor.
Este vai ser o programa consumidor de vários módulos. Por exemplo, este consumidor depende do módulo a e depende do módulo b e depende do módulo c.
E cada módulo que a dependência do consumidor depende do módulo chamado x.
Note que o módulo a depende do módulo x, o módulo b também depende do módulo x e o módulo c também depende do módulo x.
Essas três dependências dependem por si próprias do mesmo módulo x.
Mas a versão é diferente. O módulo a requere módulo x na versão 1.6.2.
Então, no módulo b requer módulo x na versão 1.7.4.
O módulo c, finalmente, requer a versão do módulo x 1.8.0, que é mais atual neste caso, nesta lista de versões.
Então, neste caso, quando o gol compilar o programa consumidor, que depende de módulo a, b e c, que por si próprios depende do módulo x,
qual versão do módulo x o gol vai escolher? Será que a mais baixa é 1.6.2, ou é a do meio 1.7.4, ou é a mais atual desta lista, 1.8.0?
Então, vamos ver. Primeiro eu gostaria de falar de versões semânticas.
Então, vamos aqui.
No inglês, semétric vergonim, a sigla também é chamada de semver.
O que é que é isso? Então, um padrão de numeração de versões de software.
Neste padrão, a versão é numerada da seguinte maneira.
Você digita v, seguido de o número x, ponto número y, ponto número z.
Certo?
Por exemplo, v1.0.0, v1.2.0, v1.2.3.
Agora, o que é que cada número x e v2.0.0 significa?
Vou te explicar aqui. Então, o primeiro que é o x, é o número à esquerda, tem três números.
A esquerda, depois do v, é a versão maior, major.
E o número do meio, entre os pontos, é a versão menor, no inglês minor.
E, finalmente, o último número à direita, no final, é o remendo, no inglês patch.
Então, o que é que é isso?
Então, cada número desses tem um significado se você obedecer o padrão semver.
Toda vez que você fazer uma mudança no software e você lançar uma nova versão,
qual que é o número que você vai incrementar?
Bem, depende das mudanças que você fez.
Então, deixa eu te explicar maior.
O número maior vai ser incrementado e todos os números à direita serão zerados.
Quando você tiver a mudança no seu código, que vai quebrar os programas que dependem do seu programa.
No inglês, é chamado Breaking Change.
Uma mudança que, se você atualizar da upgrade para essa nova versão,
o seu programa que depende desse software não vai mais funcionar, vai quebrar.
Então, se isso acontecer, você teria que incrementar o número à esquerda.
Nesse caso, por exemplo, 1, 2, 3, iria se tornar 2 e você zera o do meio e o da direita.
Agora, vamos para menor, que é o número do meio.
Menor seria quando você adiciona funções adicionais ao seu código, seu programa.
Então, você iria incrementar o número do meio e iria zerar o número à direita.
Isso significa funções adicionais que não quebram o software como ele está.
É apenas algo a mais que você adiciona.
As coisas que já tinham continuam, na mesma maneira.
Vou te dar um exemplo aqui.
Por exemplo, se o 1, 2, 3 aqui da linha 13,
se eu adicionasse algo a mais, mais as outras funções antigas ainda funcionasse da mesma maneira,
eu aumentaria o número do meio, que é o 2 para 3 e zeraria o número à direita.
Então, nesse caso, 1, 2, 3, iria se tornar 1, 3, 0.
Está certo?
Agora, vamos falar de patch ou remando.
Você incrementa o número à direita, se você consertar algum bug naquela versão menor.
Então, patch, que é o número à direita, no final da numeração, é para o conserto de bugs.
Isso significa que não houve nenhuma mudança radical no código e também não houve nenhuma adição de função.
O que já existia, tinha algum problema, algum bug que foi consertado e agora ele funciona em comportamento correto.
Nesse caso, você só incrementaria o número mais à direita da numeração.
Por exemplo, no 1, 2, 3, se o programa, a próxima versão só tivesse um conserto de bugs, você aumentaria do 3 à direita para 4.
Então, versão 1.2.3 se tornaria 1.2.4.
Está bom?
Eu quero que você note que quando muda a menor ou quando muda o patch, não há uma quebra do programa.
Não há a breaking change, como é a mudança da maior.
Isso é importante, porque, por exemplo, entre a versão 1.2.0 e 1.2.3, eu poderia usar ambas.
No meu programa e não haveria nenhuma quebra.
Poderia também usar a versão 1.0.0 em um programa.
E você poderia atualizar para 1.2.0 e não iria quebrar nada, porque a 1.2.0 seria uma incrementação da versão menor, que seriam funções adicionais.
Então, como eu estava usando a versão 1.0.0, eu estava usando as funções antigas que já existiam.
Quando eu dar o upgrade para 1.2.0, novas funções serão adicionadas, mas como meu programa não usa essas funções adicionais, não irá ocorrer nenhuma quebra no meu programa.
Então, é importante essa que eu acabei de falar, porque é isso que o Go vai usar para determinar qual versão usar.
Se lembra desse lance de funções adicionais e do seu programa, não usar essas funções adicionais.
De volta aqui ao desenho.
Vamos analisar na maneira Samver.
O módulo X usa Samver.
A primeira versão é 1.6.2.
A versão maior é 1, o número maior é 1, o número menor é 6 e o remando é 2.
O que significa o que?
Houve alguns bugs do .0, então, o .2 à direita significa que houve dois lançamentos em que os bugs foram concertados.
Agora, essa próxima módulo B usa a versão 1.7.4.
O que significa?
Significa que houve uma adição de certas funções da versão 6 menor para 1.7.4.
Mas note que se o módulo A usa as funções da 1.6 e o módulo B requer em 1.7, que tem coisas adicionais,
o módulo A ainda vai funcionar se estivesse usando o .7, porque as funções adicionais que vieram no 1.7 não são usadas pelo módulo A.
Agora, o módulo C usa a versão mais nova nessa lista de versões aqui, nesse caso, 1.8.0.
Então, mais uma versão menor, que é o número do meio, que adicionou mais coisas.
Agora, o módulo B, que tem a versão 1.7, com certeza não vai usar as novidades da versão 1.8, que foram adicionadas.
Então, por isso, A ainda funciona se eu tivesse usando o .8 no módulo B.
Da mesma maneira, o .8 no módulo A também funcionaria.
Então, isso eu já te dei a dica de qual o gol que vai escolher, né?
E vai escolher a 1.8, porque tem coisas adicionais que o B nem o A vai usar, mas ainda funciona no A e no B,
porque as coisas antigas ainda permanecem da mesma maneira, porque não houve uma quebra de mudança com a versão maior.
Note que a versão maior dos três modos ainda é a versão 1.
Vamos aqui continuar a falar da escolha do gol.
Então, acabamos de falar de versões semânticas, semantic versioning, semver.
Agora, vamos falar da maneira que o gol escolhe e eu acabei de dar a resposta, né?
Então, no inglês, minimum version selection, MBS, é o que o gol usa, traduzindo essa versão de versão mínima.
Mas esse mini não significa que ele vai escolher a versão mais antiga, então não confunda com isso.
Isso significa que ele vai escolher a versão mínima, cujas funcionalidades estão disponíveis para cada módulo.
Nosso caso era 1.8 lá, que tinha funções adicionais que só o módulo C precisaria, então o módulo B e nem o A não precisam,
mas o C precisa então a mínima, nesse caso, seria 1.8.
Mas, claro, para isso funcionar direito, tem que ter a pré-condição aqui, que na linha 3 tem o que eu escrevi,
que o módulo, as dependências, tem que obedecer o padrão sem ver corretamente na numeração das versões.
Isso significa que ele tem que obedecer essas regras aqui que a gente acabou de falar da maior só com T breaking change,
da menor ter funções adicionais e do remendo ter concerto de bugs.
Se não obedecer, aí vai dar problema.
Nesse caso, o módulo teria que consertar o padrão de versões para que o gol possa funcionar corretamente.
Tá bom?
Então, de acordo com essa seleção de versão mínima, no nosso exemplo, a resposta seria o módulo X de versão 1.8.0,
que seria usado para fazer a build do consumidor.
Para confirmar isso, eu fiz um exemplo para vocês verem aqui.
Eu tenho aqui no lado esquerdo, eu queria um pacote consumidor.
Eu tenho um gol.mod, que define as dependências do módulo A, módulo B, módulo C.
Eu queria esses módulos aqui localmente, por isso que tem que ter esse replays,
que realmente não está hospedado aqui nesse domínio.
Então, ele depende de módulo A, B e C.
Eu queria o módulo A aqui no lado esquerdo, que tem um pacote que o gol.mod dele é.
Nesse caso, eu usei como dependência compartilhada entre todos os módulos, o gorilamax,
github.com, barra gorila, barra mox.
Nesse caso, versão 1.6.2 requerida pelo módulo A.
Para módulo B, requer em versão 1.7.4.
Para módulo C, requer em 1.8.0.
Certo?
Certo?
Agora vamos aqui demonstrar qual versão ele vai usar na build final.
Como é que eu posso saber? Ah, qual é que o gol vai usar?
Será que é 1.8, como a gente espera, né?
Ou é 1.7.4 ou é 1.6.2? Como é que eu confirmo isso?
Bem, a gente pode usar o comando golista.
Isso aqui no meu terminal.
Dentro da parte do projeto consumidor, eu posso falar gol, espaçoList, espaçoTraxUm, espaçoO.
Isso vai listar as dependências módulos.
TraxUm significa listar os módulos em vez de pacotes.
E all é todos.
Então ele mostra quais são as dependências módulos em que o programa consumidor depende, módulo consumidor depende.
Nesses casos, a gente está interessado no gorila mox.
Github.com.grilla.mox e ele diz que vai usar a versão 1.8.0 e isso confirma o que a gente esperava.
Tá certo?
Se você quiser fazer um exercício, você pode remover o módulo C.
E você vai ver que ele vai usar a versão do módulo B que é 1.7.4.
Que confirmaria, se você tivesse o módulo A e o módulo B, nesse caso a versão mínima,
seria 1.7.4, que seria mínima para funcionar em todos os módulos.
Nesses casos 1.7 teria algo adicional a 1.6, que o módulo A não precisaria, mas o módulo B precisa ter.
Então funcionaria no A, porque ele ainda estava usando as funções antigas, que ainda tem na versão 1.7.
E para o módulo B ele usa talvez as funções mais novas, então precisaria 1.7.4.
E assim por diante você pode dar a módulo A e ver o que acontece, ou dar a módulo B
e confirmar com o gol, list, traço M, all.
Tá bom pessoal?
Então espero que vocês tenham gostado dessa aula e até mais.
Tchau!


0021-08 Como o Golang Escolhe que Versão da Dependência Usar (Versões Semânticas e Seleção Mínima)

Como Manter uma Cópia de suas Dependências de Golang no seu Repositório (Vendoring)

```markdown
# Aula de Golang: Vendoring

## O que é Vendoring?
Vendoring é o processo de manter uma cópia das dependências do seu projeto dentro do repositório. Isso é útil para garantir que as versões exatas das dependências estão disponíveis, especialmente em equipes ou organizações que preferem ter controle total sobre o que está incluído no código.

### Exemplo Prático
- Imagine que você tenha um módulo chamado **Currency** que depende de outras bibliotecas, como Mux.
- Para realizar o vendoring, você cria uma pasta chamada **Vendor** na raiz do seu projeto.

## Como Fazer?
1. Acesse o terminal na pasta raiz do seu projeto.
2. Execute o comando:
   ```
   go mod vendor
   ```
3. Isso criará a pasta **Vendor** com cópias de todas as dependências do seu projeto.

### Resultados Esperados
- Uma pasta **Vendor** será criada contendo cópias de cada dependência.
- Um arquivo **mod.txt** também será gerado, contendo informações sobre as dependências.

### Vantagens e Desvantagens
- **Vantagens:** Você tem controle sobre as versões das dependências que seu projeto utiliza.
- **Desvantagens:** A inclusão das dependências pode ocupar espaço no repositório.

### Removendo o Vendoring
Se você deseja remover o vendoring, basta deletar a pasta **Vendor**.

É isso! Vendoring é simples e ajuda a gerenciar dependências de forma eficiente. Até a próxima aula!
```

Olá pessoal, estamos de volta com mais uma aula de Golang.
Nesta aula vou falar de Vendoring.
O que é Vendoring?
Vendoring é quando você tem as dependências do projeto e você mantém uma cópia dessas dependências no seu repositório.
Por exemplo, eu tenho aqui um certo módulo que eu criei e ele depende de duas dependências.
Nesse módulo chamado Currency, em linha 7, no Mux.
Então, Vendoring é quando a gente pega e tem uma cópia de cada dependência e você faz um comete dessa cópia no seu próprio repositório para ter cópia lá.
Cetas companheias e organizações gostam de ter isso, essa funcionalidade.
Então, vou te ensinar como fazer, bem simples.
Você vai lá no terminal, na pasta-raís do seu projeto e você digita GolModVendor.
GolModVendorVNDoA
O que acontece é que eu criei uma pasta chamada Vendor na raiz do projeto e dentro da pasta tem uma cópia de cada dependência, de cada módulo do seu projeto.
Nesse caso, getfail.com.br, BNK, Malest e Gorilastam aqui.
Você pode ver que a gente tem uma cópia de cada dependência no seu repositório e você pode incluir com a pasta-vendor, como parte do seu repositório, e fazer o comete dela.
A vantagem é que você sempre vai saber exatamente o que vai ser incluído no projeto.
A desvantagem é ter que incluir isso e vai ocupar espaço no repositório.
Tá certo pessoal?
Se você quiser remover Vendor, é só deletar a pasta.
Então é só isso, bem simples.
GolModVendor e uma cópia de cada dependência será criada dentro da pasta Vendor.
Ele criou esse arquivo mod.txt também, com as coisas aqui sobre as dependências.
Por essa aula é só e até a próxima.


0021-09 Como Manter uma Cópia de suas Dependências de Golang no seu Repositório (Vendoring)

Como Fazer uma Faxina e Retirar Dependências não Mais Usadas no seu Módulo de Golang

```markdown
# Aula de Golang: Limpeza de Módulos

Olá pessoal! Estamos de volta com mais uma aula de Golang. Nesta aula, vou ensinar como limpar os módulos que você não usa mais no seu projeto, ou seja, as dependências que já não são necessárias.

## Exemplo Prático

Vamos supor que meu projeto depende de dois pacotes: `currency` e `mox`. Se eu decidir que não preciso mais do `currency`, o primeiro passo é remover todas as suas referências do código, especificamente no arquivo `main.go`.

1. **Remover Referências**: Exclua o código que faz referência ao pacote `currency`.
2. **Atualizar Módulos**: Embora você possa remover manualmente, é importante que o sistema de gerenciamento de módulos do Golang também seja atualizado. 

Para automatizar essa atualização, você utiliza o comando:

```bash
go mod tidy
```

## Execução do Comando

Após remover todas as referências no código, abra o terminal na raiz do projeto e execute:

```bash
go mod tidy
```

Após executar esse comando, você pode verificar o arquivo `go.mod` e notar que a dependência do pacote `currency` foi removida, confirmando que o Golang atualizou corretamente as dependências.

## Conclusão

E é isso! Com apenas alguns passos simples, você pode limpar as dependências não utilizadas no seu projeto. Até a próxima aula!
```

Olá pessoal estamos de volta com mais uma aula de golang, módulos de golang, vou te
ensinar como fazer uma limpeza dos módulos que você não usa mais, as dependências que
você não mais precisa. Eu tenho meu projeto aqui que depende de duas coisas, desse pacote
currency e desse pacote mox. Vamos supor que eu não preciso mais do currency, eu vou lá no meu
código, main.go e não vou mais usar currency, então vou remover do código, remover e não tem mais
referência a esse modo. E aí como é que eu faço para remover isso? Mas é claro que a gente pode
remover aqui, manualmente, mas também vai ter que ir lá no golsang e ver as corretão lá também.
Então há uma maneira também de você automatizar isso, sem precisar escrever manualmente,
delatar manualmente e que o golsang também seja atualizado, é bem simples, a gente vai usar o
comando golmods, tidy. Então vou te mostrar aqui. Então eu acabei de remover as referências e tal e
vamos ver lá no meu terminal, falar gol, espaço mod, espaço tidy, tidy.
Depois de executar golmod tidy, eu vou lá no meu golmod, eu vejo que não tem mais o requerimento
do currency que eu tinha antes e agora o golmod, o gol.sang também foi atualizado, não tem mais
referência ao módulo currency que eu tinha antes. Tá certo? Então é bem simples, eu modifiquei
meu código, removi todas as referências daquele módulo que eu não uso mais e com isso é só ir
terminal na parte da raiz, digitar gol, espaço mod, espaço tidy, tidy, tidy.
Por essa aula é só e até a próxima.


0021-10 Como Fazer uma Faxina e Retirar Dependências não Mais Usadas no seu Módulo de Golang

Como Fazer Downgrade e Upgrade de Dependências de Módulos de Golang

```markdown
# Aula de Golang: Módulos e Gerenciamento de Versões

## Introdução
Nesta aula de Golang, abordaremos o gerenciamento de módulos, especificamente como fazer upgrade e downgrade de versões de dependências.

## Conceitos Básicos
- Um projeto em Golang pode depender de outros módulos.
- A discussão se limitará às versões menores e de remendo (patch).
- Versões maiores (ex: de 1 para 2) são tratadas de forma diferente e serão discutidas em outra aula.

## Exemplo com Gorilla Mux
Utilizaremos o pacote **Gorilla Mux** como exemplo. Para verificar as versões disponíveis:

1. Acesse o repositório do **Gorilla Mux**.
2. Clique em **tags** ou **releases** para visualizar as versões.

A versão mais atual é **1.8.0**.

### Instalação da Versão Atual
- No terminal, execute:
  ```bash
  go get github.com/gorilla/mux
  ```
- O arquivo `go.mod` será atualizado para incluir:
  ```
  require github.com/gorilla/mux v1.8.0
  ```

### Downgrade para Versão 1.7.0
Para fazer downgrade para a versão **1.7.0**:
- Execute:
  ```bash
  go get github.com/gorilla/mux@v1.7.0
  ```
- O arquivo `go.mod` agora mostrará:
  ```
  require github.com/gorilla/mux v1.7.0
  ```

### Upgrade para Patch 1.7.4
Para atualizar para a versão de remendo mais nova **1.7.4**:
- Execute:
  ```bash
  go get github.com/gorilla/mux@v1.7.4
  ```
- O arquivo `go.mod` refletirá a nova versão:
  ```
  require github.com/gorilla/mux v1.7.4
  ```

### Upgrade para Versão Menor 1.8.0
Para atualizar para a versão menor mais recente (de 1.7 para 1.8):
- Execute:
  ```bash
  go get github.com/gorilla/mux@v1.8.0
  ```
- O arquivo `go.mod` mostrará:
  ```
  require github.com/gorilla/mux v1.8.0
  ```

## Conclusão
Na aula, aprendemos a:
- Instalar dependências em Golang.
- Fazer downgrade de versões.
- Atualizar para versões de remendo e menores.

A atualização para versões maiores (ex: de 1 para 2) é mais complexa e será abordada em uma próxima aula. 

Espero que tenha gostado da aula e até a próxima!
```

Bem-vindo a mais uma aula de Golang. Na sala vou falar mais de módulos de Golang.
E vou falar de como você fazer upgrade ou downgrade de versões de dependência.
Vamos supor que você tenha um projeto, um módulo de Golang.
E seu projeto depende de outros módulos.
E esses outros módulos você quer instalar esse módulo, você quer fazer o downgrade da versão e depois você quer fazer um upgrade.
Nessa aula só vou falar da versão menor e da versão de remando, patch.
A versão maior é outra coisa e a versão que você falava vai ser versão 1.
Então menor que 2.
No caso de versões maiores que 1, a coisa muda um pouco se for fazer o upgrade de versão maior, por exemplo, de 1 para 2, de 2 para 3, se em pôr diante.
Vamos lá.
Como exemplo, eu vou usar o pacote Gorilla Barramux.
Estou aqui na página do repositório do Gorilla Barramux.
Se você quiser verificar quais versões desse módulo de Golang são disponíveis, só clicar em tags ou no lado direito, barra lateral, releases.
E clicar na atual ou na mais x, outros releases.
Se clicar em tags fica mais fácil de visualizar a lista compacta.
Então você vê que a versão mais atual de Gorilla Barramux é 1.8.
E tem outras versões 1.7 com vários remendos.
1.4, 2.3, 1.
versão 1.6, por diante.
Primeiro vou instalar esse módulo usando o Golgat.
Então eu tenho aqui o meu projeto, tenho meu Golmode, o arquivo já criado.
Vou no terminal e vou falar Golgat.gat.com.barramux.
Dessa maneira vai baixar a versão mais atual sendo 1, certo?
Sendo 1.
Depois a gente vê a versão 2 para cima, que é um pouco diferente.
Então com isso o meu Golmode foi modificado.
Tem uma entrada no require para guirhel.com.barramux.
Espaço V 1.8.0.
Então ele instalou a versão mais atual na maior 1, da V1.
Legal, vamos supor que a gente queira fazer o downgrade,
ficar alguma coisa que quebrou, tem um bug nessa versão e você tem que fazer o downgrade.
Para a versão 1.7.
Meu exemplo eu vou usar uma versão 1.7.0,
só para a gente poder depois saber como fazer o upgrade para o remendo 7.4.
Então vai no terminal, deixa eu diminuir aqui para você ver as versões do lado esquerdo.
Golgat, Golspacogat.gat.com.caminho do modo.
Gorilla.mux, agora você botar uma rouba no inglês at.
V, a versão desejada, nesse caso 1.7.0.
Note que eu estou fazendo downgrade da mesma versão maior.
Note que eu estou fazendo downgrade da mesma versão maior.
Estou fazendo downgrade da mesma maior, mais do a menor de 8 para 7.
A menor é o número do meio.
Voltando aqui ao meu editor de texto,
agora está 1.7.
Legal, mas que tal a gente fazer o upgrade para o patch mais novo,
sem ter que mudar a versão menor, que é o número do meio.
Quero mudar o número da direita, para mais recente, que é 1.7.4, de acordo com a página do GitHub.
Vamos para fazer isso, vamos lá no terminal,
fala golspacogat.gat.com.caminho do modo.
Tem que ter a opção aqui, entre o get e o caminho do módulo, você vai botar a opção traçoU igual patch.
Golgat, traçoU igual patch. TraçoU igual patch tudo junto.
Você vê que ele diz que atualizou da versão 1.7.0 para ver 1.7.4.
Então o remedo, o patch mais atual agora faz parte do número, que é o 0.4, mais a direita.
Confirmando aqui no editor de texto, virou 1.7.4.
Agora vou te dizer como é que atualiza para a versão menor.
Bem simples, é só remover o igual patch.
Então se eu quiser atualizar para a versão mais recente menor, que é o número do meio,
nesse caso seria o 1.8.0, o 7 virou 8, e o número de remedo foi zerado,
e só remover o igual patch.
Então você fala Golgat, traçoU, o caminho do modo.
GetAway.com.barGorilla.barMax.
Pronto, então a versão menor foi atualizada de 1.7 para 1.8.
Como não tem nenhum remedo, ficou no 1.8.0 foi zerado.
Então esse aqui é como fazer, você baixa a dependência, adiciona a dependência ao seu Golgat,
faz o downgrade, fiz o exemplo de como fazer o upgrade só do patch, que é o número mais a direita,
e o upgrade só da versão menor.
Na hora de que esse caso aqui sempre foi versão 1, certo?
Vessão 1 para maior.
O caso mais complicado é a versão 2, de 1 para 2,
é um pouco mais complicado que a gente vai ter que mudar os caminhos do modo com sufixo V2.
Mas isso é outro alo.
Então espero que tenham gostado dessa aula e até a próxima.


0021-11 Como Fazer Downgrade e Upgrade de Dependências de Módulos de Golang

Como Fazer Upgrade de Versão Maior v1 para v2 de Dependências de Módulos de Golang

# Resumo da Aula sobre Upgrade de Dependências em Go

Nesta aula, o instrutor ensina como realizar um upgrade de uma dependência do Go de uma versão maior (de V1 para V2), utilizando um projeto com o arquivo GoMod.

## Principais Tópicos Abordados

1. **Instalação da Versão 1**:
   - O instrutor utiliza um módulo do GitHub, `github.com.vindtwegs.vilmos`, e instala a versão 1.2.1.
   - O Go, por padrão, instala a versão mais recente abaixo da versão maior 2, caso a versão não seja especificada.

2. **Estrutura de Dados**:
   - Demonstra o uso de uma função que cria uma pilha (stack) e explora como essa função se comporta na versão 1.

3. **Upgrade para a Versão 2**:
   - Para instalar a versão 2, é necessário especificar o caminho como `github.com/vindtwegs/vilmos/v2`.
   - O instrutor discute as mudanças que ocorrem com a versão 2, onde uma função já existente muda seu comportamento, retornando dois valores ao invés de um.

4. **Mudanças no Código**:
   - O código deve ser modificado para lidar com o novo retorno da função `new stack`.
   - No código, o erro deve ser tratado corretamente.

5. **Novos Métodos na Versão 2**:
   - Um novo método chamado `clear` é introduzido na versão 2, que não existia na versão 1.

6. **Transição entre Versões**:
   - O instrutor sugere que durante um período de transição, é possível usar duas versões do mesmo módulo. Para isso, seria necessário criar um alias para uma das versões.
   - Por exemplo, poderia-se utilizar `interpreter1` e `interpreter2` para referenciar a versão 1 e 2, respectivamente.

7. **Limpeza de Dependências**:
   - Após a transição, a limpeza das dependências pode ser feita com o comando `go mod tidy`, que remove versões não utilizadas.

## Conclusão
A aula conclui abordando a importância de entender como as mudanças nas versões podem quebrar o código existente, o que é comum ao fazer upgrades de versões maiores, de acordo com o conceito de Versionamento Semântico (Semver).

Espero que este resumo tenha sido útil! Até a próxima aula!

Bem-vindo a mais uma aula de Columbo. Nessa aula eu vou falar de como você faz um
upgrade de uma dependência da versão maior. No exemplo eu vou usar de versão
maior 1 para versão 2. V1 para V2. Para essa demonstração eu vou usar aqui o meu
projeto que já criei. Tem o meu arquivo GoMod. Eu vou baixar um certo módulo de
Golang que eu achei online no GitHub e vou demonstrar a atualização da versão 1.
O upgrade da versão 1 para a versão 2. A gente vai ver que certas uma certa
função foi adicionada na versão 2 e também vamos ver que a versão 2 quebrou
uma das funções que já existia. Por isso se tornou de 1 para 2. De acordo com
Semantic Version, que é Samver, versões semânticas. Vou aqui no meu nome
e vou usar o quebrador. Então o módulo de Gol que eu vou usar para esse exemplo é esse aqui no
GitHub.com.vindtwegs.vilmos. GitHub.com.vine.twg.
TWGS.vilmos. Se eu ver aqui nas tags tem os releases, as versões.
Tem a versão 2 maior que é o número mais esquerda depois do V e tem a versão 1.
O primeiro vou instalar a versão 1. Então vamos lá. Go, get, caminho do módulo
GitHub.com.vindtwegs.vilmos.
A note que eu não disse nenhuma versão específica, mas ele instalou a versão 1.2.1
e ver a versão mais atual que a versão 2. Isso é devido à maneira que o Gol lida
com as versões maiores que 1. Então na verdade se eu quiser essa versão 2 que é mais atual
eu teria que dizer explicitamente. Vilmos barra v2. A gente vai ver depois. Mas sem a
especificação de barra v2 aqui, que é diferente do do arroba, tá? E ele vai baixar 1. Então vamos lá.
No editor de texto. Eu tenho um exemplo no meu arquivo main.go.
Se eu salvar. Então o módulo é esse aqui. Mas eu quero usar um certo pacote desse
módulo. Então digo barra interpreter que é o nome do pacote. Deixa eu te mostrar no
editor. Voltar para o repositório arquivos interpreter. Eu quero ver stack.go. Mas eu
quero olhar a versão 1.2, né? Quero a versão 1.2.1. Porque essa aqui é mais atual. Então vamos
ver. Você clica aqui no seu editor de branch e tag. Clique em tag. Aí eu vou mudar para a
versão que eu estou usando agora no arquivo. Que é 1v1.2.1. E agora ele vai mudar para essa tag
e vai mudar para essa conta. Para aquele commit da versão 1.2.1. Então nesse ponto no tempo, né?
O snapshot desse repositório dos arquivos era dessa maneira. Então vou olhar aqui a função que
eu vou usar. Essa aqui. Você vai na linha 18 a 22. Se aumentar aqui para você ver melhor.
Então essa é uma função que vai criar uma stack, né? A estrutura de dados stack é como por
exemplo você tem pratos, né? Você empira os pratos um em cima do outro. Isso é uma stack, né? E você
sempre só pode acessar o prato lá do fundo se você tirar todos os pratos de cima. Então
essa função eu posso chamar com o número de elementos, né? Para stack e retorno o
ponteiro para stack. Essa struct aqui na linha 13. Às 16 tem os itens, né? E tem o tamanho máximo.
Então eu usei isso como exemplo. Na linha 9 do meu arquivo, main.go na função, no bloco da função
main, eu falo interpreter, né? Que é o nome do pacote. Ponto new stack, que é o nome da função
da tamanho de 4. Então eu quero que você aloca 4, uma stack de 4, tamanho 4. Você pode botar
por exemplo de pratos, 4 pratos, né? E que é o tipo, né? Retorno o ponteiro para stack que está dentro do
modo. E tem também a função de push, que é adicionar o valor a essa stack. Eu usei um, dois, três,
números um, dois, três. E no final eu faço print na linha 24. Por favor, ignore os comentários,
para ver. Vou falar aqui goal build.
Aprenda a executar. Então eu mostro aqui que a estrutura interna daquela variável, né? Que é uma stack
de 1, ponteiro para stack. A stack tem um, dois, três, que é um slice de int, inteiros, números inteiros,
e o tamanho máximo que é 4, então dá pra empurrar mais um. Então eu quero demonstrar o lance da
upgrade, né? Da versão 1 para 2. E como fazer? Bem, se eu falar goal gets, não sei o que, viu uns barra v2.
Ele adiciona essa versão aqui e você nota que a tag é mais atual da v2. Então a tag, essa barra v2 é no
caminho, certo? É diferente do arroba, nesse caso seria arroba v2.1.1, se quisesse explicitamente, digitar.
Se eu olhar o meu goal mod agora, agora vai ter também a versão 2 ao mesmo tempo, que é a versão 1. Então essa é uma das
das coisas que acontece. Você pode ter duas versões do mesmo módulo instalados ao mesmo tempo. Isso porque o caminho
é diferente. Então o caminho da versão 2 sempre vai ter o suffixo barra v2, depois do nome do caminho do módulo.
Então é parte do caminho, o suffixo da versão. Agora, se eu tiver aqui no meu main.go, ainda estou usando a versão 1, na
verdade. Porque no goal você tem que explicitamente dizer se quiser usar a versão 2 ou se tem que dizer. Então, se eu
quiser fazer o upgrade da versão 2, eu teria que mudar os meus caminhos. Cada caminho que dizia
getarra.com.bindtwegs.vilmos, agora tem que dizer também o suffixo barra v2. Nesses casos ele
quer dar o ponto com barra bindtwegs.vilmos barra v2. Então v2 teria que ser adicionado aqui ao meu import. Então todos os
import que você tem que adicionar a nova versão, v2, nesse caso, versão maior. Com isso ele vai usar o módulo da
versão 2 em vez da 1. Agora, quando a gente quiser fazer o upgrade, o problema é que a versão maior que muda, normalmente
tem a mudança que quebra o programa, porque algo que já existia foi modificado para se comportar de outra
maneira. Nesses casos a gente vai ver que vai quebrar o negócio. Quando eu botar v2 e todos esses referências de
interpreter, oh, desculpa, está errado aqui, tem que ser v2 depois do nome do caminho do módulo. Tem que ser
depois do barra v1. Então, github.com, barra bindtwegs, barra v1, barra v2. Porque esse é o caminho do módulo, a
interpretação é o nome do pacote que está dentro do módulo. Como esse módulo é, na verdade, um programa executável,
em possível própria, eu tenho que dizer barra interpreter para poder só acessar aquele pacote interpreter. Interpreter
é o pacote que é o arquivo aqui, se você ver no GitHub, de volta ao navegador, na primeira linha package interpreter.
Está esse aqui que é usado para o sufixo. Então, de volta ao editor de texto, quando eu mudar v2, barra
interpreter, vamos ver o que acontece. Quando eu falar gobuild para compilar, você note que já teve um erro de
atribuição. Falou que teve o mismatch de atribuição. One variable but interpreter, but new stack returns
dois values, né? Está dizendo aqui que a função new stack retorna dois valores. Então, o que aconteceu aqui que essa
função foi modificada, seu comportamento original. Na versão 2 retorna dois valores, em vez de só um. Para poder
confirmar isso, você pode ir na página do GitHub e comparar as versões. Deixa eu te mostrar como comparar. Vai aqui
no code, clica nas, cadê releases, tags. Você vê, eu clico na versão mais atual, versão 2. Aqui embaixo do número, clica
compare. Você coloca a versão anterior para comparar o que foi adicionado nessa versão 2. Então, a versão anterior
que eu usei foi v1.2.1. Você note na URL tem o bar compare, barra v1.2.1, que é a base do 3.v211, que é por cima.
Então, o que mudou da versão 1.2.1 para a versão 2.1.1? Vamos ver. Aqui rola para baixo. Eu estou interessado na função
new stack. Então, vou fazer uma busca new stack. Funk. Já noto aqui que a função new stack foi modificada e o retorno,
o tipo de retorno que era só um único, que era ponteiro para stack, agora se tornou um tuple, que é 2 valores retornados
ao mesmo tempo. Nesses casos, além de retornar com um ponteiro para stack, retorna o error do tipo error, que é erro.
Foi modificar o comportamento com se usa essa função. Então, essa mudança que quebrou. Então, o que você faria nos seus upgrades?
Você iria lá e qualquer chamada para a função ponto new stack, você teria que mudar o comportamento. Nesses casos,
ele só está atribuindo a uma variável. Então, eu modifiquei isso, já tenho escrito aqui para te mostrar. Eu teria que criar
duas variáveis e atribuir o valor de retorno a essas duas variáveis. Você pode usar dois pontos igual aqui e você tem que usar
var também. Eu só botei isso para poder destacar. Então, na versão 2, tem que usar assim. Então, tem que lidar com o erro.
Então, interpreto retorno stack e além de stack, vim para o error. E o erro, se não for new, é botar o mensagem.
Acho que é só um exemplo pessoal. Isso aqui não é sério. Então, só botei algo para ele não reclamar que não estou usando
a variável error. Com isso, vou salvar, falar Google Build. Vou executar o notic que funcionou direito. Então, outra coisa
aqui, nessa nova versão, adicionar a função, vamos ver aqui, clear. Vamos usar essa função. Depois vou reverter para você ver que
quebra o negócio. Então, vou linha 22 e botar stack.clear, que não existia antes da v21. Vamos comparar a versão 1 que eu tinha.
Falar Google Build, executável executável. E note que ele deu clear. Clear significa limpar, remover todos os elementos da pira.
Nesse caso, virou vazio. Cocheiro vazio. Agora, se eu tirar o v2 aqui, usar a versão 1. E se você quiser tirar esse require,
eu vou usar o go mod tidy depois de remover todas as referências da versão anterior dos imports. Nesse caso, como os imports do meu aqui não tem mais versão 1,
é só dar o go mod tidy, go mod tidy e ele removeria a versão anterior. Mas eu quero deixar aqui só para você ver o que acontece.
Então, quando eu tirar esse v2 e fazer ele usar o v1, vai quebrar, né? A gente já viu que tinha quebrar mesmo.
Na hora de criar stack, também no stack clear é indefinido, porque não existe essa função, esse método no stack.
Agora, como que te mostra que é interessante? Você pode usar duas versões ao mesmo tempo.
Vamos fazer isso, ó. Te mostrar aqui. Se você quiser fazer um certo período de transição, você copiaria e botava mesmo com o v2,
mas você tem que dizer uma alias, porque eles não podem ter o mesmo nome, né?
Ou você dá para o v1 ou para o v2. Eu não sei qual que você quer. Por exemplo, normalmente se chama interpreter, né?
Então, aqui você fala interpreter, aí você coloca, sei lá, v2, algo assim.
Dá um nome diferente, ou 2, sei lá, interpreter 2.
Aí, onde tiver a função que só existe no 2, né? Que quer usar do 2, você vai lá. Por exemplo, clear, só tem no 2.
Então, teria que usar... O problema que que stack é do interpreter 1.
Ah, deixa eu ver. É o como usar do... Usar o do 2 aqui, isso é um problema.
Ah, vamos ver.
No record module... Ah, desculpa.
Sempre esqueço. É o v2 depois do modo caminho, não do pacote.
Então, o problema é que tem que usar stack do 2, né?
É o meu problema. Vamos usar outro exemplo. Vamos ver o new stack, por exemplo.
Se eu quisesse já... Eu poderia usar o new stack do interpreter 2, nesse caso, para não quebrar aqui.
Vamos ver qual é o problema. Não dá para assinar o 2 ao stack do 2.
Então, eu tenho problema aqui, na verdade. Na maneira que esse exemplo não é muito bom.
Porque não é função isolada, né? É pertença ao... Tem um método que é associado à estrutura.
Então, porque as estruturas são diferentes, de modos diferentes, não funciona direito com esse exemplo.
Mas o ponto que eu queria demonstrar é que você tivesse funções e transição de certo modo,
se você poderia só dar um alias aqui, enquanto estivesse em transição, você colocaria 2, algum outro nome diferente do primeiro.
Aí, fazia transição e depois de tirar todas as referências do 1, você só mudaria de volta para o nome aqui.
Acho que poderia ficar melhor no 1. Não sei, você escolhei. Tem que pensar nisso.
Em vez de falar 2, você fala interpreter 1, então você fazia uma substituição global de todos os interpreters.
Nesse caso, o primeiro aqui seria 1. E o 2 seria o mais atual, seria como já existia.
Aí você faria a limpeza procurando em transição. O período de transição seria o pessoal das equipes.
Então, teria que como tarefa, substituir interpreter 1 pelo normal que é o 2. Então, esse seria o período de limpeza nesse caso.
Então, recapitulando tudo para poder dar upgrade, versão 1 para a versão 2.
Ou, em geral, a versão 2 é acima.
O caminho do módulo tem que clicar como sufixo vx, onde x é o número da versão. Nesse caso, v2.
Então, caminho do módulo barra v2.
Caminho do módulo barra v2. Cada import que você tem em todos os arquivos, você tem que modificar isso para caminho do módulo barra v2.
Se tiver período de transição, pode usar duas versões ao mesmo tempo, mas ter que criar um alias para uma das versões.
Ou você quer ir para a versão 1 e põe sufixo 1 ou v2, sufixo 2, por exemplo, e usa 2 ao mesmo tempo até que você termine a limpeza de tudo.
Fazia transição e só usar a nova versão.
Porque certamente, certos elementos vão não quebrar.
Depois que terminar isso tudo, só dá o GoModTide e vai remover a versão anterior.
Vou mostrar.
Tirei tudo das versões anteriores.
Vou aqui. Go, espaço mod, espaço tide, T, I, D, Y.
Ele removeu a versão anterior e agora está a versão mais atual.
Tá bom pessoal? Então, por essa aula é só. Espero que tenham gostado dessa.
E até a próxima.


0021-12 Como Fazer Upgrade de Versão Maior v1 para v2 de Dependências de Módulos de Golang

Como Fazer o Lançamento de uma Versão Maior v1 para v2 de um Módulo de Golang

# Resumo da Aula de Golang: Lançando uma Nova Versão de Módulo

## Introdução
Na aula de hoje, o instrutor ensina sobre **módulos em Golang**, especificamente como lançar uma nova versão de uma biblioteca que quebra a compatibilidade com versões anteriores.

## Estrutura da Aula

1. **Descrição do Módulo**
   - O módulo é uma biblioteca que oferece uma função chamada `novoLivro`. Esta função retorna um ponteiro para uma estrutura `Livro`, que contém informações como `publicado em` e `título`.

2. **Versão Atual**
   - A biblioteca está na versão 1.0.3 e é usada por outro módulo chamado `consumidor`.

3. **Quebra de Mudanças**
   - Para a nova versão, uma mudança simples será feita: a ordem dos parâmetros da função `novoLivro` será alterada, o que quebra compatibilidade com os consumidores da biblioteca.

4. **Métodos para Lançar uma Nova Versão**
   - **Método 1: Criar um Novo Diretório**
     - Copiar todos os arquivos para um novo diretório chamado `v2` e aplicar as mudanças.
   - **Método 2: Criar um Novo Branch**
     - Criar um branch (galho) no repositório que representa a nova versão, por exemplo, `v2`.

5. **Demonstração Prática**
   - O instrutor demonstra como criar o branch `v1` para armazenar a versão atual antes de fazer as mudanças no `master`.
   - A mudança é feita e a tag `v2.0.0` é adicionada ao repositório.

6. **Atualização do Consumidor**
   - O módulo consumidor precisa remover a versão antiga e fazer as alterações necessárias nos imports e chamadas da função para utilizar a nova versão `v2`.

7. **Verificação de Compatibilidade**
   - O instrutor verifica que tanto a versão nova quanto a versão antiga funcionam independentemente e descreve o uso do comando `go mod tidy` para limpar dependências não utilizadas.

## Conclusão
A aula finaliza com um convite para os espectadores se inscreverem e comentarem, e agradecimentos pela participação.

---

Essa aula fornece uma compreensão prática sobre como trabalhar com versões de módulos em Golang, destacando a importância de manter compatibilidade e as estratégias para gerenciar versões de forma eficiente.

Olá pessoal, estamos de volta com mais uma aula de Golang. Vamos falar de módulos
nesta aula e eu vou te ensinar como lançar uma versão nova de versão 1 para a versão 2
de uma biblioteca de Gol. Vamos fazer o seguinte, eu tenho aqui um módulo de Gol que é uma biblioteca,
essa biblioteca é usada por outros módulos de Gol, então a dependência de outros programas que
são os consumidores dessa biblioteca. Então está na versão 1 maior, mas eu queria lançar a nova
versão, versão 2 que iria quebrar umas mudanças, essa versão 2 terá mudanças que irá quebrar o código
dos consumidores da dependência se eles utilizarem a nova versão. Então vamos lá, para demonstrar isso
teremos dois módulos separados, o que está aberto aqui é meu arquivo gol.mode do meu primeiro
arquivo que é 0021 golmódulo biblioteca. Então esse primeiro repositorio tem o golmode que define o
módulo e tem um arquivo livre.go que é a função aqui que eu quero disponibilizar para os outros
programas usarem, neste caso a função novo livro, função bem simples, eu tenho uma estrutura aqui
o livro que representa um livro, um livro no ano de publicação chamado publicado em e a propriedade
título. A função novo livro leva dois argumentos, o primeiro publicado em que é o inteiro e segundo
título que é um string, essa função retorna um ponteiro para o livro que é um struct. Então
eu vou usar um livro literal aqui e retorno com 1%. Publicado em e o título, então ele que apenas cria
uma nova instância de um livro. Esse módulo está na versão 1 maior. Deixe-me mostrar aqui
ele já hospedado no GitHub, se eu clicar tags eu já adicionei a tag para cada comete dele. Então a versão
mais atual a versão 1.0.3, remedo 3, maior 1. Voltando no editor de texto tem uma outra pasta
chamada 0021 traço-go, traço-módulo, traço-consumidor. Essa pasta requer tem como dependência a biblioteca
que a gente acabou de ver no outro diretório. Eu estou usando a versão aqui 1.0.3. E é um programa bem
simples no arquivo main.go, tem a funk main que é a função principal, chama o método novo livro do
nosso pacote biblioteca. Noja que o diretório da biblioteca tem um arquivo lebe.go, mas eu defino
o package com biblioteca, por isso que aparece lá no consumidor biblioteca. Não tem a ver com o nome do
arquivo nem com o nome do diretório na hora de referenciar o nome do pacote. É claro que para ficar
com as coisas seria melhor você nomear o pacote na mesma nome que o arquivo e que o nome do
projeto. Depende, se tiver múltiplos pacotes, mas tiver só um seria ideal. De qualquer maneira, o
nome do pacote definido no arquivo é que vai ser referenciado lá do consumidor. De volta ao diretório
do consumidor main.go, quando a gente faz um import com o caminho do módulo que é o gethaw.com,
nvkmundo.tech, 0 0 21 traço go, traço módulo, traço biblioteca, ele vai disponibilizar aquele
package chamado biblioteca. Então eu posso dizer biblioteca. novo livro e passo com os argumentos
do primeiro, que é o ano de publicação do livro e o segundo o título. Eu passei 1857,
isso retorna o ponteiro para o livro, mas o livro está dentro de biblioteca, então eu tenho que
dizer estrelabiblioteca.livro. Amazônia isso não variava e aprendam que chamam println do pacote
FMT. Bem simples, não tem nada demais, é só para demonstrar o lançamento de uma alversão no
módulo da biblioteca. Vamos supor que lado da biblioteca, de volta ao diretório da biblioteca,
leib.goarchivo, na linha 10, vamos supor que eu vou quebrar essa função, isto é, eu vou modificar
a assinatura da função, o comportamento dela para ser diferente do original. Eu vou fazer uma coisa bem
bem simples, vamos mudar a ordem dos parâmetros. Em vez de ser publicado em primeiro e título segundo,
o título vai ser título como primeiro parâmetro, vírgula publicado em como segundo. Se eu fizer isso,
é claro que vai quebrar lá o pacote consumidor, porque ele teria que trocar o argumento 1 com
argumento 2. Então, isso que eu vou fazer. Para poder lançar a alversão, qual é a maneira?
Tem duas maneiras principais, uma maneira é você criar um diretório, copiar os arquivos
para aquele diretório e implementar a nova versão só com aqueles arquivos naquele diretório.
Claro, eu acho que eu não sou fã desse porque tenho que fazer uma cópia, eu prefiro usar controle
no caso de um diretório, que é o segundo, a segunda maneira. A segunda maneira é você criar um
branch, um galho no get branch e esse branch você chama do nome da versão. Por exemplo,
pode ser a versão nova ou pode ser a versão antiga, você escolhe, eu prefiro a nova lá. Não, eu prefiro a
antiga, eu acho. Então, você pode criar esse branch e chama v, por exemplo, se você escolher que o
branch vai armazenar na alversão, eu chamo o branch nesse caso de v2, o nome do branch é v2. Se eu
quiser armazenar a versão velha no branch, que é que eu prefiro, eu vou dizer que esse novo branch
vai armazenar a versão v1 e ele vai capturar o código da versão 1 nesse branch v1. Aí o da v2 vai ser
o branch principal, que é o master, no meu caso. Então, você escolhe, se quiser fazer do novo, o branch
vai ser o novo ou o branch vai ser a versão velha. Se você fizer a versão velha, como acabo de dizer,
o branch principal sempre vai ser a versão mais nova. Se você fizer o contrário, então o branch
principal, nesse caso, seria a versão antiga e você criaria v2 para o branch da versão nova.
Então, vamos ver isso na prática. Vamos lá. Vou demonstrar, vamos ver o que eu faço. Eu quero focar
o branch, mas eu vou demonstrar só rapidinho o da pasta. Então, essa parte inicial é diferente,
mas o resto que a gente vai fazer é similar. Então, a parte de criar pasta, se você escolher
para criar pasta, eu criaria aqui a pasta aqui, chamaria de v2, mas tem que copiar todos os arquivos
que você tem aqui para a pasta v2. Então, copia aqui o código.
Basicamente, tem que copiar tudo, né? Seria mais rápido não terminar, mas deixa.
E aí
E aí, agora vamos lá no gmod desse de dentro. Você vai colocar a barra v2,
no caminho é adiciona sufix v2. Aí você faz as mudanças aqui no novo código, por exemplo,
para trocar a ordem dos parâmetros. Está aí pronto, já estaria preparado e ia para a próxima
etapa que eu vou explicar depois. Agora eu vou reverter e vou explicar do branch.
Vou ver se está aí. Vou ver ver. Vou fazer o do branch. Vou ver aqui. Estou no
módulo consumidor, quero para o módulo biblioteca. Ok, então, que branch eu estou?
O branch no principal que é master. Qual é a minha tag agora? Se eu olhar o log, o master
agora está 1, 0, 3. Ok, então vou falar get, checkout, traço b. Eu vou falar v1.
Ok, agora o v1 está apontando até aqui, esse commit, que é a versão anterior. Agora eu vou fazer o
odynamic, vou voltar para o master. Agora eu vou modificar o code como se fosse a nova
versão. Então, se eu voltar o meditor de texto, libe.go, troca a ordem dos parâmetros do
método de função novo-lib. Troquei. Vou fazer o commit. A ordem dos parâmetros foi trocada.
Ok, mas eu também tenho que mudar a versão aqui do go-mode para o suffix barra v2 no caminho
do módulo. Vou deixar isso um nice também. Da ordem de parâmetros de novo-lib.
Ok, vamos supor que você tenha vários commits, até que chegou ao ponto de lançar.
Ok, então vamos lá. Eu vou fazer get tag, espaço v2.0.0. Eu vou dar push, traço, traço tags e push normal.
A ordem do espaço master, a mesma coisa, que é o meu principal. Se eu olhar no get hub, atualizar tags, agora tem 2.0.
Se eu olhar aqui e comparar com a versão anterior, eu vejo que agora é barra v2 no go.mode e os parâmetros foram trocados.
Agora vou lá no pacote consumidor e verificar.
Então, esse processo que eu acabei de fazer vai na mesma na maneira de criar o diretório.
Se você tem o diretório lá v2, você iria fazer a tag naquele ponto.
Vamos ver o módulo consumidor para o módulo consumidor.
Para poder usar a nova versão do consumidor, você teria que estar lá como se fosse o novo módulo, porque o caminho seria diferente, com barra v2.
Então seria no terminal, módulo consumidor, goget, getup.com, barra nvk, módulo tag, barra 0021, traço, módulo, traço, biblioteca, barra v2.
Você baixou.
No go.mode do consumidor, agora tem v2.
Se eu ir lá no main.go no arquivo e eu botar a barra v2 aqui, ele vai quebrar.
Eu fiz o upgrade do consumidor.
Se eu falar go build, quebrou porque os argumentos foram trocados.
Então, da parte do consumidor, ele teria que trocar a ordem de todas as chamadas dessa função para poder funcionar novamente.
Então, recapitulando.
Temos um repositório de um módulo de biblioteca.
Para poder lançar a versão 2,
há uma maneira de você criar um diretório, chama v2, copia todos os arquivos lá, faz as mudanças lá e aplica a tag de v2.0.0.
Outra maneira, através do branch, galhos de get.
Nesses casos, tem duas maneiras.
Você faz o branch da versão nova.
Nesse caso, seria get checkout, traço b v2, faz as mudanças lá e depois terminar a mudança, fazer o commit, aplica a tag v2.0.0.
Ou você pode fazer a maneira que eu fiz, que eu foquei aqui, que é do branch principal.
Você criou um branch com a versão vela v1, que chama de v1.
Depois, volta para o branch principal, nesse meu caso master.
Começa a fazer mudanças no master.
Depois de fazer o commit, não esqueça de mudar o go-mode, o caminho do modo tem que ter o suffix o barra v2.0.
Lá.
Aí, quando estiver feito o commit dessas mudanças, aplica a tag get tag v2.0.0.
Puxa a tag para o repositório, servidor e puxa o branch.
O branch não, o branch principal, as mudanças.
E isso lança.
E já do pacote consumidor, se ele quiser fazer o upgrade, ele teria que mudar todos os imports e adicionar o suffix o barra v2.
E modificar a chamada da, no meu caso, chamada da função.
E outros pacotes seriam outras coisas que quebraram, né?
Teria que consertar ou ajeitar, reordenar as coisas.
Tá certo? Então, deixa eu voltar o consumidor.
Como não estou usando mais o antigo.
Eu vou dar o tidy aqui para ver se ele remove o anterior.
Go-mode tidy.
Então, seria o fim do upgrade.
Mas eu quero reverter só para ver se está funcionando direito.
Então, vou reverter isso na implementação. Vou reverter v1.
E isso eu falava o build quebrou.
Ah, não tem, né?
Então, vou lá go get a isso aqui.
Vamos ver se ainda funciona a versão anterior.
Ele adicionou no go-mode v1.0.3.
Vou falar o go-mode tidy para tirar outra versão nova, que eu não uso mais.
E eu vou confirmar que realmente a versão velha ainda está lá.
Não foi quebrado.
Então, funcionou direitinho.
Então, a versão velha também é disponível para baixar, para download.
E funciona sem problemas.
A versão nova também funciona sem nenhuma interação, conflito com a versão anterior.
E de volta aqui na página do Getts, pode verificar as mudanças e tal.
Se você clicar em tags ou releases.
Tags.
Está certo, pessoal?
Então, por essa aula é só. Muito obrigado por assistir.
A peça que se inscreva, este comentário, né?
Não se esqueça das notificações.
E agradeço muito e até a próxima.
