"Ask for Insights on first run." breaks automation.
tthew opened this issue · comments
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.
Obviously, we can do something like yes no | bower install but it's a bit hacky.
Agreed. Silent should be silent.
👍
👍
👍
Using worker: worker-linux-9-1.bb.travis-ci.org:travis-linux-14
try @oroce's solution:
bower install | xargs echo
should work
Or use bower@1.2 :)
👍 This is causing issues with my codeship build as well.
I don't think bower install -s is viable here... We shouldn't be forced to use a silent option with an automation tool just to keep it from asking us questions in build environments. I would say make this an opt-in(preferable) or opt-out in .bowerrc.
This must be an opt-in. Releasing this feature just broke thousands of travis build scripts.
For reference, the CHANGELOG recommends using --config.interactive=false for automated scripts.
<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 --config.interactive=false to the documentation/help?
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.
We already have the --config.interactive=false mentioned in the readme.
Hey guys, average user here. I'm new to the whole Grunt/Yeoman/Bower thing, so please bear with me. I was learning how to build an app with yeoman/generator-mobile (yo mobile) when the process just stopped for no apparent reason. After a minute or so, I hit enter to test if the generator was still responsive and then this popped up:
[?] May bower anonymously report usage statistics to improve the tool over time? Yes
I'm not 100% sure whether I had accidentally scrolled up a line or not, but I'm fairly certain that the line wasn't in the output. In any case I didn't see it, and didn't intend to allow usage statistics. How do I deactivate them? Is this a setting hidden somewhere in the generated app or is this in some hidden bower config files? Can't find it in .bowerrc, but then again I have no idea what I'm doing here anyway. I'm currently blocking the script from phoning home with Little Snitch but that's not really satisfactory and bower.io has no information on it. Help, anyone?
@jdahdah I think you've raised a very good point, we need more documentation surrounding general config & analytics.
I've added a PR to address your concerns, and will ensure that its tracked through appropriately.
For now, please keep all further commentary regarding disablement of analytics to the PR, or a new issue altogether.
I agree. install/update must always be silent. May be a good option would be to only show that prompt on bower help.
@ikr 👍
This was fixed a while back. If you're having problem please update bower to latest version or open a new ticket. This should be locked.
If it still asks for insights on first run, it's not fixed. That behavior is fundamentally flawed.
I haven't checked, I'm just going by https://github.com/bower/bower/blob/master/bin/bower#L71 which still says "Ask for Insights on first run". This should never happen, even when the CI env var and --silent are unset. It should just not be in the code at all.
@stuartpb you can't really challenge the issue based on opinion and state that the functionality is flawed. That's the way it is, it's done that way for a reason.
A better way forward would be to make a proposal that can be discussed for its merits.
Otherwise, I'm locking this issue as it's resolved.
I thought the reasoning against this was laid out pretty succinctly above, but to sum it up, prompting on first run (unless the user specifies some variables they have no reason to expect they'd need):
- breaks existing code
- breaks automation
- breaks workflows on newly-imaged machines
- interrupts users when they're busy with other things
This isn't just my opinion- this is the stated experience and problems of ~10 users, right here, just on this issue.
Also, I did make a proposal: output a warning that your analytics preference hasn't been set, but don't stop anything over it.
I personally don't mind if it even defaults to being on. Just so long as there's a warning about it, and clear instructions in the warning on how to disable it.
If encouraging users to participate in analytics is the goal here, then surely there's a better way than simply documenting the status quo and leaving it.
I think the if (process.stdout.isTTY) { askForAnalytics() } should fix most of problems.
@stuartpb I don't buy it. apt-get will also break if you try to script without using the -y flag.
Bower does the same, only the flag is --config.interactive=false
Existing code, if broken, has been broken since February when analytics shipped (admittedly, it should've been more than a point release, but that is another story).
@sheerun Good suggestion. I think we should absolutely do that.
@benschwarz I'm not sure apt-get is a great paradigm, since apt-get asking questions is a) crucial to its functionality, b) has been happening since its inception, and c) not built into most CI build scripts.
The fact is, millions of builds have been run based on the expectation that bower isn't going to ask trivial questions, and one day, everything goes to hell. apt-get's behavior is neither equivalent not relevant here.
I came across Bower for the first time today (via Zurb Foundation). Setting up a simple Salt state which I expected to run, didn't happen - which led me to read this whole comment thread.
So yeah, broken for a first time user. +1 for changing.
Just looked over the diffs in #1470. While that's better (assuming config.interactive is determined by some automated method like process.stdin.isTTY and not an absurd unspoken command-line option), I'm still not satisfied with it:
-
It still interrupts the user and breaks unattended (but still nominally "interactive") installation. Again: use warnings, not prompts.
Real life example: I was getting ready to go to a meetup, at which I was looking to tell people at the meetup about a new site I was working on with another developer. In a few spare moments, I pulled the code, ran "bower install", and walked away to get dressed while Bower installed. When I came back, I found that nothing had installed, because Bower had popped up an annoying "Do you want to help make Bower blah blah blah give us your info? [Y/n]" prompt instead of just doing what I'd asked when I asked it. As a result, I missed my bus waiting for Bower to finish downloading so I could deploy the site, and had to show up at the meetup after all the seats were taken, and all the pizza and beer was already gone.
This was a fucking terrible user experience, and it's led me to swear off Bower for all future projects I work on a dev team with. If it were fixed so that nothing like this will ever happen again, I'd reconsider that stance.
-
If no preference is specified, it defaults to opt-in - it needs to default to opt-out. The worst-case scenario defaulting to opt-out is you're going to miss some sample points in your analytics, and some devs don't get to be as smug as they could have been about their massive, throbbing metrics.
The worst-case scenario defaulting to opt-in is you violate developers' deeply-held religious beliefs about privacy and eavesdropping, ever steadily eroding their faith in humanity (don't know if you've noticed, but some people really care about this stuff).
FYI 1.3.10 may have broken tracking, we're investigating it: #1507 (comment)
@stuartpb thanks for the review. Here are my thoughts:
- Can you expect a tool to know it's unattended if you don't tell it so?
- I hear you on privacy concerns. The reason why we pour so much effort into collecting and surfacing stats is because the community asked for and love it. The anonymous data we track isn't any different than what's in the server logs that the registry server generates. We're using GA purely for convenience. We're fully transparent on what we track (https://github.com/yeoman/insight#collected-data). Do you know what data npm / apt-get / nuget is tracking, and are they asking for your permission?
Can you expect a tool to know it's unattended if you don't tell it so?
Yes. Any tool that isn't strictly interactive should consider itself unattended. That is exactly what I expect.
Do you know what data npm / apt-get / nuget is tracking, and are they asking for your permission?
I don't know about nuget (some Microsoft thing? I'll trust it as far as I can throw 'em), but AFAIK, the only analytics either npm or apt-get have (if they have any) are done on the registry rather than in the tool, from the anonymous information I'm already giving them by requesting packages. I could probably ask isaacs or Debian (or Canonical) what analytics their registries have implemented and they'd disclose it if somebody cared (I know npmjs.org keeps download counts because it shows them).
Either way, they've never interrupted me to ask if I can give them more.
It seems like all of this is caused by relying on third-party (GitHub) hosting. If there were dedicated Bower servers, then there would not be a need for the client to have this functionality at all.
What if project owners gave Bower permission to access their traffic statistics in GitHub? But then, why would these people not just be using GitHub traffic statistics directly? /shrug
Would it be possible to negotiate (if necessary) for the Bower client to point to packages in the npm registry? Although, I guess at that point we all may as well be using npm. /shrug
Now that npm hosting has been improved and they openly welcome front-end packages, has there been any work on merging key Bower features into npm and merging the communities?
@stuartpb Please try 1.3.10. Fresh installs shouldn't prompt.
FWIW, here's the output from my local machine
‣ $(npm bin)/bower --version
1.3.8
‣ $(npm bin)/bower info bootstrap
[?] May bower anonymously report usage statistics to improve the tool over time? (Y/n)
^C
‣ $(npm bin)/bower info bootstrap
[?] May bower anonymously report usage statistics to improve the tool over time? (Y/n)
^C
‣ $(npm bin)/bower --version
1.3.10
‣ $(npm bin)/bower info bootstrap
bower bootstrap#* cached git://github.com/twbs/bootstrap.git#3.2.0
bower bootstrap#* validate 3.2.0 against git://github.com/twbs/bootstrap.git#*
{
name: 'bootstrap',
description: 'The most popular front-end framework for developing responsive, mobile first projects on the web.',
version: '3.2.0',
keywords: [
'css',
'js',
'less',
'mobile-first',
'responsive',
'front-end',
'framework',
'web'
],
homepage: 'http://getbootstrap.com',
main: [
'less/bootstrap.less',
'dist/css/bootstrap.css',
'dist/js/bootstrap.js',
'dist/fonts/glyphicons-halflings-regular.eot',
'dist/fonts/glyphicons-halflings-regular.svg',
'dist/fonts/glyphicons-halflings-regular.ttf',
'dist/fonts/glyphicons-halflings-regular.woff'
],
ignore: [
'.*',
'_config.yml',
'CNAME',
'composer.json',
'CONTRIBUTING.md',
'docs',
'js/tests',
'test-infra'
],
dependencies: {
jquery: '>= 1.9.0'
}
}
Available versions:
- 3.2.0
- 3.1.1
- 3.1.0
- 3.0.3
- 3.0.2
- 3.0.1
- 3.0.0
- 3.0.0-rc1
- 3.0.0-rc.2
- 2.3.2
- 2.3.1
- 2.3.0
- 2.2.2
- 2.2.1
- 2.2.0
- 2.1.1
- 2.1.0
- 2.0.4
- 2.0.3
- 2.0.2
- 2.0.1
- 2.0.0
- 1.4.0
- 1.3.0
- 1.2.0
- 1.1.1
- 1.1.0
- 1.0.0
You can request info for a specific version with 'bower info bootstrap#<version>'
@jfsiii: sorry, I was just going off of the code in the diff which still appears to have the prompt in it: https://github.com/bower/bower/pull/1470/files#diff-57594d2f4dd5a157b08c4b6d5eadb147R30
works ok - I mean silently as expected from any decent tool - by using the --config.analytics=false option from #1470 ... so I now have:
bower --config.analytics=false install
Just wanted to express my frustration with this.
Which one is it now if we want an automated build flow like the one we used to have since ever?
1. bower --config.analytics=false install
2. bower --config.interactive=false install
3. bower --config.interactive=false --config.analytics=false install
??????
Setting an environment variable of CI=true on your CI server is a good start. Bower respects that, as do other tools.
@benschwarz CI is not the only environment where builds are performed.
Still waiting on an answer on how to properly, unobtrusively, silently invoke bower install. Setting an ENV var is a different approach and frankly not fit for our use case.
@thanpolas env vars can be added inline to one-off processes too. Not sure how that won't work for you, but happy to step through it.
Otherwise, I recommend reading the source to see. Doesn't seem like such a mystery to me.
Otherwise, I recommend reading the source to see. Doesn't seem like such a mystery to me.
Sure, why bother with documentation or a plain answer. On it, starting to read the codebase...
CI=trueis equivalent to passing--config.interactive=false- attaching a pipe to bower is equivalent to
--config.interactive=false --config.interactive=falsecauses--config.analytics=falseto be a default
The answer is, use one of the following:
CI=true bower install
bower install --config.interactive=falseDocumentation was already pretty clear on it.
I've additionally documented exact behavior of non-interactive mode: bower/bower.github.io@19b9934
@desandro Could you review it linguistically?
Small mistake:
bower/bower.github.io@f602fbd
lgtm
@sheerun nice! 👍
This is still messing me up today. Can't you get usage statistics from your server?
Just ran into this issue while writing a Vagrant provisioning script. This default behavior is intensely annoying. It's even more annoying that I had to Google how to resolve it. Why isn't this flag documented in bower --help?
This is still messing me up today. Can't you get usage statistics from your server?
No, we're not able to get everything that we want. What can we do to make things better for you?
Why isn't this flag documented in bower --help?
I'm not sure! Would it be too much to list every single configuration option in --help?
I'd say any config flags that make it into the API docs should be documented at the primary point of contact with the API.
The comparison was made earlier to apt-get -y. You don't need any other resource but --help to figure out how to turn off apt prompting.
@benschwarz I'd rather have you not ask to collect analytics at all, like most other command line tools that I use. NPM seems to work just fine without asking me for them.
Here's the list of collected data from your docs. Could you tell me what items you cannot get on the server and why you need them?
- The version of the module that implements Insight
- Module commands (e.g. install / search)
- Name and version of packages involved with command used
- Version of node.js & OS for developer debugging
- A random & absolutely anonymous ID
Is the random/anonymous ID generated once per install of bower or once per transmission of analytics data? Also, do you collect and store my IP Address on the server side?
Thanks.
@benschwarz Please also consider these points:
(TL;DR: Things are not OK with this feature. People don't like it and you broke things to have it, which makes it seem like there is a hidden agenda here.)
- Searching for the terms: bower statistics, you see mostly bugs and complaints.
- Nobody seems to be giving you analytics anyway, going by the low numbers seen at bower.io/stats.
- Given that nobody seems to be using this bug-causing, breaking-change of a feature - it makes me wonder why the bower team is fighting so hard against the seeming majority of people who don't want it.
This all seems very untrustworthy to me and I'll probably jump ship as soon as it is practical. I might just be one guy but I'm representative of many and people in general (and developers in particular) are pretty sick of having their tech constantly trying to track and analyze everything we do under the guise of "making the product better".
@benschwarz I guess my final point would be this: Your documentation says it's opt-in but it's really not because we have to do all this work to turn off the feature. If it were actually opt-in, you would just display a message about it and tell people to run a different command to enable it or tell them how to turn it on.
The extra work that must be done whenever the analytics question feature is activated at an unexpected time is this:
- Figure out what is causing the problem.
- Go and make changes to code and/or configuration files.
That does not sound like an opt-in. That is a hard opt-out. You're not really introducing an opt-in feature when at the same time you introduce a new opt-out anti-feature.
tldr; Analytics suck support-wise, and frustrates everyone ever involved in this conversation. I want analytics to be printed out and shot at the sun. 🚀☀️💥
@waynebloss, let me take a second to remind you that your insinuation that the bower team has done something unjust here is slightly upsetting.
We're predominantly volunteers, many of us are independents; Let me reassure you that there is no ill-will, nor hidden agenda. We get plenty of comments from people like you, with the same tone, and to be honest, it is wearing.
Analytics were added to improve Bower, and the ecosystem around it – to help the team understand what people were doing with it. Given its rate of growth from nothing to now, theres no wonder we wanted to know what was happening out there. Specific items aside — just how many people were using it? How often? Daily? Multi-daily?
Without something like insights, we'd never have been able to open the data up to new contributors like @rayshan, who built Bower stats as a side project.
That said, you've made one interesting point:
Given that nobody seems to be using this bug-causing, breaking-change of a feature - it makes me wonder why the bower team is fighting so hard against the seeming majority of people who don't want it.
No one is fighting for the feature — Since it was added people have had all the issues that you've mentioned. It sucks. It sucks support-wise and it sucks for people who choose to deploy or server-side-build with Bower.
When installed, Bower does ask if you'd like to submit analytics, and has numerous, documented methods for disabling it if you made the wrong choice or didn't answer. We made Bower ask, because it was the right thing to do. Turns out, it is incredibly annoying.
I know too well that a silently hanging script on the server is a total pain in the ass to find and fix, and it wastes time too. I totally understand your frustration.
I think it'd be a lot easier to pull out analytics entirely (or, find someone to donate their time to replacing it with something else). If you want to make that very pull request, I'd be happy to review and campaign for it to get through.
@bower/bower, thoughts?
If we, the Bower team, are not actively using analytics to drive decisions, then let's remove it.
@benschwarz I understand that collecting anonymous usage data can help with development decisions. I think just making this a non-interactive message that explains how to opt-in without waiting for a "y" or "n" would be an immense improvement. It might also mean you can display the message more often, and in more circumstances, to get more eyeballs on it.
@benschwarz, @desandro and @bower/bower team - Sorry for the insinuation, I was just giving you my point of view as an outsider. I don't know anything about the people who built this or their motivations. Also, maybe I'm paranoid due to the fact that this battle against everything tracking me is one that I have to fight every day. Anecdotally, I think a lot of people think like me but I could be wrong (because I don't have those stats! 😄 )
If it's useful to anyone, why not just take out the question and let it be enabled via config? You could just print out a message that says something like "Please enable analytics to help our project by doing x. Read about how we're not invading your privacy here..."
IMO, if you really wanted those stats, I think you'd get more people with a short, polite but persistent nag message.
@benschwarz I'd rather have you not ask to collect analytics at all, like most other command line tools that I use. NPM seems to work just fine without asking me for them.
Nooooo!! Bower is special! Bower is super special, it is not anything like the other scripts! The whole lot of the other open source packages, libraries, scripts and whatnot are really peasants compared to Bower, least would they dare to ask users for collecting their data and hanging deployment scripts around the globe losing us collectively thousands of work hours and millions of USD on debugging.
I believe we should remove the flags to turn off interactive all together and go all in, make the web and devops industry crawl to a stop, because, bower.
And then go on and force ask questions about the developer's health, well being and if they woke up well today, then we can also provide life coaching services apart from package management which is what we always really wanted to do.
This whole conversation smacks of Microsoftian-level user hostile design from the Bower team. Your community has been unequivocally clear for months that they hate this, yet you refuse to address it despite great alternative suggestions. I've already done my time digging through my CI job late in the evening finding out why the F bower decided to break it all of the sudden, and golly I'd like that time back.
Regardless of the outcome of this particular debate I feel you have done irreparable harm to your credibility from the perspective of one of your users, and my team and others we work with have begun the P.I.T.A. work of moving our package management to npm.
@brainfish, Do you feel good for posting that? I hope you do. Did you or your team ever consider contributing rather than deciding to post something like that? No? … I didn't think so.
I plan to make a strike on changing this, because I know it frustrates people. It doesn't personally bother me (because I just use the flags, like the docs explain), but I want to do it for people.
Like I've said before, if someone wants to make the first strike on this, I'll be the first person ready to support you. Comments like @brainfish's don't help anyone. Open source people, open source.
@benschwarz, take a look at #1921 (primarily the concept of it). That would at least make the tool less likely to break automation and cause less friction.
@mex (First of all.... what's up, buddy?!) I'm not sure I like the idea that it perpetually adds 10 seconds to all affected workflows, which gives the impression that a) the process is just slow, and b) nothing really needs to be addressed. This is like failing to check under the hood of your car when it feels less powerful, instead of being forced to check when the engine blows up.
@benschwarz That said, I'm not sure I agree with your expectation the community that we provide a PR that fixes something that was broken intentionally. The community has spoken quite loudly, and I think we would all prefer that analytics die completely if it they can't get out of our way. Collecting stats CANNOT prevent the tool from working properly, which it's currently doing.
Part of the problem is that this was a HUGE breaking change. If this were a brand new tool that had analytics included from the beginning and everyone hopped in without reading the readme, the burden is on them to fix it. But when you enforce a certain standard of reliability and introduce something crazy like this, people get upset, and I can't say I blame them.
So again, can we make this an opt-in process? I don't think anyone had an issue with that. If you have an issue with it, can we hear what that is?
Or what if analytics were enabled, the option to disable is retained, but the interactive prompt was eliminated? I wouldn't mind if it happily reported statistics without asking me, as long as it doesn't blow up my automation.
So again, can we make this an opt-in process? I don't think anyone had an issue with that. If you have an issue with it, can we hear what that is?
I've said it before — I don't have any issue in changing the behaviour. I donate my time to projects like bower when I can. Its not my responsibility to do anything here. I was going to make some changes last week, until a comment on this thread made me want to throw my computer into space 🌃
Lets get a change through and forget this ever happened 💪
Like I've said before, if someone wants to make the first strike on this, I'll be the first person ready to support you. Comments like @brainfish's don't help anyone. Open source people, open source.
@benschwarz thank you on the lesson. This is open source, discussing, no, rather, asking, for the permission of the maintainers of the repository to remove the feature. That's how it's done.
- You announce/ask for something you want / intend to do
- The maintainers refuse the change
- You ask again
- The maintainers refuse the change
- Bunch of people go wild with the issue
- You play the open source card
- Somebody get's to do the 10' minute patch
I'm unsubscribing from this issue.
@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 git revert, which would suit me just fine as well.
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 process.env.CI and adds a fallback on 30 sec, if no response is given to the prompt.
@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:
- Most of the command statistics (except maybe install counts) are not useful
- "Top packages" is of questionable use too, because installs are counted only install directly, like
bower install jquery. They don't show total download/star count for modules. Ideally they should show trending repositories within packages registered in Bower registry (something like https://github.com/explore) - "Popularity around the world" section seems not useful as well
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:
- npm installs of bower, per version
- daily number of new stars for each "component" registered in bower
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.
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.