-
-
Notifications
You must be signed in to change notification settings - Fork 1.8k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
"Ask for Insights on first run." breaks automation. #1102
Comments
Obviously, we can do something like |
Agreed. Silent should be silent. |
Until bower/bower#1102 is fixed
👍 |
1 similar comment
👍 |
try @oroce's solution: |
Or use bower@1.2 :) |
👍 This is causing issues with my codeship build as well. |
Solves the problem :-) Thanks!! |
I don't think |
This must be an opt-in. Releasing this feature just broke thousands of travis build scripts. |
For reference, the CHANGELOG recommends using |
<sarcasm>Oh that's great that the changelog mentions that. Totally makes up for a huge breaking change on a 0.1 version bump release.</sarcasm> |
Rolling insight out is a little painful but please hang in there, in the long run stats will be very beneficial to the community (think dashboard and API to query per-package stats #1164 (comment)) |
Is there a command we can run to manually opt-in when (or just after) we first install bower? That would be my preference, to make one change right at the beginning instead of having to change every single automated script I have. |
Can we please add |
I would really prefer this to be manually opt-in rather than opt-out. Bower, like any other tool, should play nicely with automation (in any form): for example, we're using it on a build server, where setting a "CI" variable would be a touch inaccurate. I think an acceptable style to copy would be Git's behavior in 1.8 and 1.9 when the default push mode is unset: print a warning that the mode is unset, and give the commands that should be used to opt in or explicitly opt out, but don't halt the entire thread of execution over it. |
Also, behaviors like this are leading us to strongly consider abandoning Bower altogether in favor of just vendoring scripts into the tree manually. We don't have time for tools that expect to be babysat. |
@arcreative, you know, work all the time as always. I agree with you though that this isn't the most optimal solution, but it is at least better than the alternative. I did think about simply suggesting a I think skipping the prompt and defaulting to opt in would be a big mistake, because a lot of people care deeply about what data are shared from their systems. |
@thanpolas Thanks for being so polite/constructive and chasing away the only maintainer that was willing to help us with this. I'm glad you seem to be so clear on the open source process--didn't realize it entailed being an arrogant ass about everything. I'll be sure to employ this tactic in the future, since it seems to work so well for you. His suggestion was to SUBMIT A PR for it, not insult him until he created a PR for you. |
Maybe we can end this discussion with this: #1923 This both adds a check for |
@arcreative i'm afraid you got it all backwards. Bower is not reliant on a single entity, here's where open source comes in. If the issue is the PR i'd gladly submit it myself. The problem here is that Team Bower would not accept such a PR. If that's not the case, then mea culpa and i'll promptly submit a PR ripping off the whole analytics system from its roots. |
I like the idea of just removing analytics altogether because nobody here voiced any real need for them to be collected in the first place. The only purpose that I could gather is that they're needed for some website that we're not sure if anyone is using. |
Adding a timeout to "fix" this problem seems like a terrible idea. Could someone please explain to me why we need these analytics so badly? Why not just make this thing truly opt-in by removing the prompt altogether? |
I don't like the way @thanpolas behaves in this thread, but here is my proposal anyway: Personally, I agree that:
I think we need http://bower.io/stats/ to show that bower is still alive (for example to show what versions of bower are still installed and used), and to show pulse of packages registered in bower registry (for example show "Top 50 starred repositories in last 7 days)"). Because most of packages in Bower's public registry come from GitHub, I think we could remove analytics from Bower if we could retrieve following counts:
And re-implement http://bower.io/stats using these statistics I hope core team agrees with it and I hope someone will donate his/her time to make it happen :) |
Of course if the things I mentioned are done, we'd remove analytics from Bower, completely. |
They caused more issues than useful they were. Instead, we'll focus on fetching statistics from NPM registry to watch Bower's popularity, and GitHub stars over time to watch packages' popularity.
Can everyone on the thread make sure to treat other people working on this with respect, I am pretty ashamed at the level of discourse on this issue. I know it is easy to talk down and shame people, but honest mistakes are made in software. Unless you are going to help please try and be positive, and thank @sheerun for donating his time to fix this. Thanks you @sheerun !!! |
We need to wait for @npm to publish per-version download counts (it's extremely useful statistic for any package owner, it's shame it's not available), but otherwise http://bower.io/stats is updated and #1102 ready to merge. |
Remove analytics from Bower, fixes #1102
When issuing
bower install
for the first time even with the-s
option present bower asks 'May bower anonymously report usage statistics to improve the tool over time? (Y/n)' which breaks automated tools not expecting interaction (i.e. Travis).Would be great if we could provide an answer as a part of the command or at least for the
-s
option to be respected.The text was updated successfully, but these errors were encountered: