Go: cmd/go : aller extrêmement lent sans retour par défaut

Créé le 17 nov. 2016  ·  3Commentaires  ·  Source: golang/go

Quelle version de Go utilisez-vous ( go version ) ?

$ go version
go version go1.7.3 darwin/amd64

Qu'est-ce que tu as fait?

go get semble n'avoir aucun retour utile par défaut.

Reproduire:
go get github.com/die-net/dhtproxy
Cela semble alors geler pendant environ 10-15 minutes. Il n'y a pas de retour.

J'ai finalement compris que je pouvais :
go get -u -v github.com/die-net/dhtproxy
Pour voir les progrès, et il semble que parce que youtube/vitess est absolument gigantesque, cette commande prend une éternité.

Que vous attendiez-vous à voir ?

Je m'attendais à voir quelque chose du genre "Récupérer un projet, récupérer des deps, installer des deps, etc", avec une sorte de barre de progression.

Qu'avez-vous vu à la place ?

Rien. Il reste là pendant environ 10 minutes. Je pensais qu'il était cassé.

La solution est évidente - activez -v par défaut. C'est une conception CLI terrible d'avoir un processus exécuté pendant 10 minutes sans sortie par défaut, il semble juste qu'il soit cassé.

FrozenDueToAge

Commentaire le plus utile

La règle du silence n'est pas que les programmes doivent être absolument silencieux à moins qu'il n'y ait une erreur ou qu'une sortie soit spécifiquement demandée, c'est que les programmes ne doivent pas sortir inutilement. Compte tenu des commentaires selon lesquels un processus qui prend 15 minutes ne s'est pas bloqué n'est pas inutile, en fait, c'est une bonne conception de CLI.

Pour référence, aucun (0) des autres gestionnaires de packages que j'ai testés n'est silencieux par défaut.

$ pip install test
Collecting test
  Downloading test-2.3.4.5.tar.gz
Building wheels for collected packages: test
  Running setup.py bdist_wheel for test ... done
  Stored in directory: /Users/rjones/Library/Caches/pip/wheels/0e/83/0d/f0f92214b5cce4bcbce4958ddacebf926e1c54c8445f0ba167
Successfully built test
Installing collected packages: test
Successfully installed test-2.3.4.5
$ npm install test
/tmp/
└─┬ [email protected] 
  └── [email protected] 

( npm a un indicateur --silent pour cette fonctionnalité)

$ brew install test
Updating Homebrew...
==> Auto-updated Homebrew!
Updated 2 taps (homebrew/core, homebrew/versions).
==> New Formulae
homebrew/versions/postgresql95
==> Updated Formulae
ruby ✔                                                                          tig                                                                             tile38
==> Deleted Formulae
homebrew/versions/postgresql93

Error: No available formula with the name "test" 
==> Searching for similarly named formulae...
These similarly named formulae were found:
cpptest                   cxxtest                   gjstest                   homebrew/science/swetest  memtester                 slowhttptest              testdisk                  unittest                  vttest
cpputest                  git-test                  homebrew/games/minetest   js-test-driver            phoronix-test-suite       speedtest_cli             testssl                   unittest-cpp
To install one of them, run (for example):
  brew install cpptest
==> Searching taps...
These formulae were found in taps:
homebrew/completions/ctest-completion                       Caskroom/cask/aja-system-test                               Caskroom/cask/nsregextester                                 Caskroom/versions/emacs-pretest
homebrew/emacs/test-simple                                  Caskroom/cask/colortester                                   Caskroom/cask/sqlitestudio
To install one of them, run (for example):
  brew install homebrew/completions/ctest-completion

etc.

Je pense que dire "parce que c'est Unix" est un peu fallacieux. Il est _extrêmement_ commun pour les programmes Unix avec des tâches de longue durée d'avoir des barres de progression - voir rsync, wget, git, etc.

Quel est l'avantage de ne pas avoir de barre de progression ici ? Il semble que les avantages de "ne pas sembler totalement cassé" l'emportent largement sur les avantages de "ne pas ennuyer un petit pourcentage d'utilisateurs qui détestent les commentaires et refusent également d'utiliser --silent ".

Tous les 3 commentaires

C'est la méthode Unix : être silencieux par défaut, à moins que la verbosité n'ait été demandée ou qu'il y ait une erreur.

Je ne pense pas que ce soit quelque chose que nous allons changer. Encore plus de gens seraient contre ce qu'ils considèrent comme du spam (-v) par défaut.

La règle du silence n'est pas que les programmes doivent être absolument silencieux à moins qu'il n'y ait une erreur ou qu'une sortie soit spécifiquement demandée, c'est que les programmes ne doivent pas sortir inutilement. Compte tenu des commentaires selon lesquels un processus qui prend 15 minutes ne s'est pas bloqué n'est pas inutile, en fait, c'est une bonne conception de CLI.

Pour référence, aucun (0) des autres gestionnaires de packages que j'ai testés n'est silencieux par défaut.

$ pip install test
Collecting test
  Downloading test-2.3.4.5.tar.gz
Building wheels for collected packages: test
  Running setup.py bdist_wheel for test ... done
  Stored in directory: /Users/rjones/Library/Caches/pip/wheels/0e/83/0d/f0f92214b5cce4bcbce4958ddacebf926e1c54c8445f0ba167
Successfully built test
Installing collected packages: test
Successfully installed test-2.3.4.5
$ npm install test
/tmp/
└─┬ [email protected] 
  └── [email protected] 

( npm a un indicateur --silent pour cette fonctionnalité)

$ brew install test
Updating Homebrew...
==> Auto-updated Homebrew!
Updated 2 taps (homebrew/core, homebrew/versions).
==> New Formulae
homebrew/versions/postgresql95
==> Updated Formulae
ruby ✔                                                                          tig                                                                             tile38
==> Deleted Formulae
homebrew/versions/postgresql93

Error: No available formula with the name "test" 
==> Searching for similarly named formulae...
These similarly named formulae were found:
cpptest                   cxxtest                   gjstest                   homebrew/science/swetest  memtester                 slowhttptest              testdisk                  unittest                  vttest
cpputest                  git-test                  homebrew/games/minetest   js-test-driver            phoronix-test-suite       speedtest_cli             testssl                   unittest-cpp
To install one of them, run (for example):
  brew install cpptest
==> Searching taps...
These formulae were found in taps:
homebrew/completions/ctest-completion                       Caskroom/cask/aja-system-test                               Caskroom/cask/nsregextester                                 Caskroom/versions/emacs-pretest
homebrew/emacs/test-simple                                  Caskroom/cask/colortester                                   Caskroom/cask/sqlitestudio
To install one of them, run (for example):
  brew install homebrew/completions/ctest-completion

etc.

Je pense que dire "parce que c'est Unix" est un peu fallacieux. Il est _extrêmement_ commun pour les programmes Unix avec des tâches de longue durée d'avoir des barres de progression - voir rsync, wget, git, etc.

Quel est l'avantage de ne pas avoir de barre de progression ici ? Il semble que les avantages de "ne pas sembler totalement cassé" l'emportent largement sur les avantages de "ne pas ennuyer un petit pourcentage d'utilisateurs qui détestent les commentaires et refusent également d'utiliser --silent ".

Bien que je ne pense pas qu'aucun des gestionnaires de packages que vous avez mentionnés soit de bons exemples (ils sont tous beaucoup trop bruyants tout le temps), je suis d'accord pour dire qu'une indication de progression pour go get ne pourrait pas faire de mal . GitHub en particulier a des plages de vitesses de clonage plutôt lentes, et le temps d'exécution global dépend du nombre de dépendances, ce qui n'est pas évident ou connu de l'utilisateur à l'avance, donc devoir décider activement d'utiliser -v n'est pas vraiment une excellente solution.

Maintenant, une barre de progression n'est pas vraiment une option - elle est trop bruyante par défaut, et tous les VCS ne prennent pas en charge les barres de progression par défaut. L'activation de -v par défaut est également trop bruyante.

Malheureusement, je ne peux pas vraiment penser à un mécanisme qui ne soit pas bruyant et qui fournisse en même temps suffisamment d'informations en cas de besoin.

Cette page vous a été utile?
0 / 5 - 0 notes