rake -P output is ambiguous with prereq namespaces
Avaliação
- Dificuldade
- 3/5
- Tempo estimado
- 1-2 dias
- Facilidade para iniciantes
- 68/100
- Tipo de issue
- Bug
- Clareza
- Claramente especificada
- Status de atividade
- Pouca atividade
- Stack de tecnologia
- ruby
- Domínio
- build-system, cli
Direção de pesquisa
Comece pelo ponto de entrada da saída de rake -P/--prereqs e reproduza o Rakefile mostrado na issue. Rastreie como os pré-requisitos com namespace são resolvidos para tool:run e tool:run2 e, em seguida, verifique se o pré-requisito impresso para ambos está totalmente qualificado e não é ambíguo.
Escrita pelo modelo de indexação a partir do texto da issue.
Descrição
When tasks are in a namespace, their pre-reqs "inherit" the namespace prefix.
Given the following rakefile:
task :setup do
puts "global setup, oops"
end
namespace :tool do
task :setup do
puts "setting up"
end
task run: :setup do
puts "running"
end
task run2: 'tool:setup' do
puts "running a second way"
end
end
The both tasks run and run2 have the same pre-req (setup). However, task run omits the namespace, while run2 is explicit with its pre-req's namespace. Both forms work as expected:
$ rake tool:run
setting up
running
$ rake tool:run2
setting up
running a second way
However, when the pre-req tree is printed, rake is not clear about what the pre-reqs' full names are.
$ rake -P
rake setup
rake tool:run
setup # <--- This is ambiguous!
rake tool:run2
tool:setup
rake tool:setup
The expectation is that rake -P prints the "fully resolved" pre-reqs and is thus clear about what task will actually be run. In the example above, it is not clear what tool:run's pre-req is. Is it the "global" setup, task as it appears in the -P output? Or is it in fact tool:setup because it is namespaced?
To be clear, rake's invocation behavior matches my expectations: tool:run invokes tool:setup, not setup. But this behavior is not evident in rake's --prereqs output.
- Linguagem predominante
- Ruby
- Estrelas
- 2.5k
- Forks
- 649
- Merge médio
- 4min
- PRs com merge (30d)
- 2
Preparar o ambiente
- Sem Dockerfile nem arquivo Docker Compose
- Sem modelo de pull request
- Ler o guia de contribuição
Primeiros passos
- Leia a issue inteira e depois o guia de contribuição do projeto.
- Comente na issue dizendo que vai assumir — evita que duas pessoas façam o mesmo trabalho.
- Faça um fork do repositório e trabalhe em uma branch.
- Abra um pull request que referencie o número da issue.
Mais de ruby/rake
-
Dificuldade 3/5 1-2 dias Facilidade para iniciantes 48/100
-
Dificuldade 5/5 Mais de uma semana Facilidade para iniciantes 28/100
-
FileList#<< bypasses exclusions while FileList#include respects themTalvez já em andamento @hsbt assumiu há 85 dias. Aberta
Dificuldade 1/5 Menos de uma hora Facilidade para iniciantes 45/100
-
Dificuldade 4/5 3-5 dias Facilidade para iniciantes 38/100
-
Task Options in Command-LineAberta
Dificuldade 5/5 Mais de uma semana Facilidade para iniciantes 25/100
Issues semelhantes
-
Dificuldade 2/5 1-3 horas Facilidade para iniciantes 84/100
scanaislop/aislop#476 ·
Mantenedores costumam responder em até 1 dia
-
Dependencies view: `getParent` loops forever on untitled documents, extension host runs out of memoryTalvez já em andamento Um pull request vinculado a esta issue está aberto ou já foi mesclado. Abertabug
Dificuldade 2/5 1-3 horas Facilidade para iniciantes 70/100
Mantenedores costumam responder em até 1 dia
-
area/web interface
Dificuldade 2/5 1-3 horas Facilidade para iniciantes 62/100
mastodon/mastodon#41000 · 1 reação ·
Mantenedores costumam responder em até 1 dia
-
Dificuldade 1/5 Menos de uma hora Facilidade para iniciantes 82/100
zerocracy/judges-action#2743 ·
Mantenedores costumam responder em até 8 dias
-
Deno Runtime is discontinuedAbertabug
Dificuldade 2/5 1-3 horas Facilidade para iniciantes 68/100
endoflife-date/endoflife.date#11314 ·
Mantenedores costumam responder em até 1 dia