On Tue, Feb 25, 2014 at 10:30 PM, Rob Dodson <[email protected]> wrote:
> Your statement about building an ecosystem is entirely correct. The notion >> that Bower search is the key to that kingdom I find entirely dubious. > > > I don't think it's the key—I don't think there is any one key—but it's a > huge leg up. The search built in to npm/npmjs.org drives the node module > ecosystem. > When you acquire Node you get npm right in the box. Those tools are welded together. Bower does not have an analogous relationship to the Web (at least, not yet =P). > > > On Tue, Feb 25, 2014 at 10:15 PM, Scott Miles <[email protected]> wrote: > >> Your statement about building an ecosystem is entirely correct. The >> notion that Bower search is the key to that kingdom I find entirely dubious. >> >> If I make a GitHub repository for my new project, it's available via >> GitHub search, Google search, and installable via Bower. If another tool >> comes along, it will work too. >> >> I'm not suggesting that we never publish to the Bower registry, but I >> will push back on any effort to lock ourselves into any one particular >> registry or tool. >> >> >> >> On Tue, Feb 25, 2014 at 10:00 PM, Rob Dodson <[email protected]>wrote: >> >>> I want to use Bower strictly as a dependency management tool. The rest >>>> of this stuff is scope-creep from that perspective. >>>> >>> >>> Avoiding the registry means avoiding `bower search` and I think that's a >>> very very big missed opportunity. If the success of polymer/web components >>> relies on building an ecosystem then all channels of search are crucial to >>> that success. The bower search channel is well established and we should >>> leverage it. >>> >>> >>> On Tue, Feb 25, 2014 at 8:10 PM, Scott Miles <[email protected]> wrote: >>> >>>> >> You can end up with multiple directories for the same stuff >>>> >>>> I don't see how this follows from using variations on the <package-id> >>>> argument to bower. >>>> >>>> >>>> >> Many people use bower's command line search tool >>>> >> If we don't register our packages (polymer-ajax, for example) it >>>> means someone else can squat on the name >>>> >> It feels "un-bower" like to force people to use Owner/Repo syntax. >>>> >>>> I want to use Bower strictly as a dependency management tool. The rest >>>> of this stuff is scope-creep from that perspective. >>>> >>>> There is extreme resistance in the developer world to any kind of >>>> prescribed tooling, so tightly coupling to any tool has a high cost, and we >>>> don't need to pay that cost if Bower is just one of the possible ways to >>>> get stuff. >>>> >>>> For example, I'm on record against using 'bower_components' as a folder >>>> name (all our projects use a .bowerrc to reset that name) because our >>>> components can be installed any number of ways, Bower is simply not a >>>> requirement. >>>> >>>> Bower is awesome, I'm not knocking it. But IMO part of it's awesomeness >>>> is the flexibility it offers. The ability to rename the components folder >>>> and the ability to use Org/Repo package identifiers are really the primary >>>> reasons I chose this tool over NPM. >>>> >>>> Scott >>>> >>>> >>>> On Tue, Feb 25, 2014 at 7:42 PM, Rob Dodson <[email protected]>wrote: >>>> >>>>> I'm not sure I agree with the sentiment in this case only because I'm >>>>> worried the cons might outweigh the pros. >>>>> >>>>> Here are all the cons I can think of: >>>>> >>>>> You can end up with multiple directories for the same stuff. I think >>>>> this is actually a big enough problem on its own to outweigh everything >>>>> else. There are many people who are not bower savvy who will have a tough >>>>> time debugging issues with a polymer and polymer-polymer directory >>>>> floating >>>>> around in their bower_components dir. I'm really worried about component >>>>> authors mixing Owner/Repo and registry named dependencies... >>>>> >>>>> Many people use bower's command line search tool (myself included) >>>>> which only looks at packages in the registry. If we don't register our >>>>> packages we're removing that avenue. Technically some of our packages are >>>>> registered but not all of them, which leads to the next point... >>>>> >>>>> If we don't register our packages (polymer-ajax, for example) it means >>>>> someone else can squat on the name. Which is a bit of a bummer. And folks >>>>> might install the wrong component. >>>>> >>>>> It feels "un-bower" like to force people to use Owner/Repo syntax. >>>>> Polymer is the only project I know of which goes this route. Most >>>>> libraries >>>>> that know about bower and include a bower.json have a name in the registry >>>>> that they encourage people to use. >>>>> >>>>> >>>>> The pros I can think of: >>>>> >>>>> It makes it easier to manage all of your components when you don't >>>>> have to deal with registering them. This is especially tough on a project >>>>> like polymer where components have so many interdependencies. >>>>> >>>>> You're not too tied to the bower name/brand/methodology. You don't >>>>> want people thinking that bower "owns" these components, in some fashion. >>>>> >>>>> You don't have to fight over a registry name. If someone had already >>>>> registered polymer-ajax it wouldn't be a big deal to keep using >>>>> Owner/Repo. >>>>> >>>>> >>>>> >>>>> Ultimately we're telling users two different ways to do it in our docs >>>>> which has to be confusing for anyone new to bower. Above all else we >>>>> should >>>>> decide which direction to go with and use it everywhere. >>>>> >>>>> - Rob >>>>> >>>>> >>>>> On Tue, Feb 25, 2014 at 7:02 PM, Scott Miles <[email protected]>wrote: >>>>> >>>>>> I'm not a fan of central registries. I've advocated using >>>>>> `Polymer/<element>` syntax since we embraced Bower, so that's my $0.02. >>>>>> >>>>>> Scott >>>>>> >>>>>> >>>>>> On Tue, Feb 25, 2014 at 3:28 PM, Marcin Warpechowski < >>>>>> [email protected]> wrote: >>>>>> >>>>>>> In my projects I have experienced some problems (version conflicts) >>>>>>> when using "polymer", since then I am using "Polymer/polymer". I am sure >>>>>>> not everyone understands bower so deep to understand the implications, >>>>>>> so I >>>>>>> think it would be good to do it consistently. >>>>>>> >>>>>>> >>>>>>> On Tuesday, February 25, 2014 10:42:28 PM UTC+1, Rob Dodson wrote: >>>>>>>> >>>>>>>> I noticed there are some polymer packages registered in the bower >>>>>>>> registry. >>>>>>>> >>>>>>>> polymer (links to components/polymer) >>>>>>>> polymer-platform >>>>>>>> polymer-elements >>>>>>>> polymer-ui-elements >>>>>>>> polymer-polymer (links to Polymer/polymer) >>>>>>>> >>>>>>>> In the polymer docs, we sometimes tell people to install from a >>>>>>>> package >>>>>>>> >>>>>>>> $ bower install polymer >>>>>>>> >>>>>>>> and we sometimes tell them to install from the repo >>>>>>>> >>>>>>>> $ bower install Polymer/polymer-elements >>>>>>>> >>>>>>>> I'm wondering if there might be an incompatibility situation. >>>>>>>> For example, if a component author adds polymer-polymer to their >>>>>>>> bower.json file, then bower is going to create a folder called >>>>>>>> "polymer-polymer" in the bower_components dir. If another author >>>>>>>> depends on >>>>>>>> "polymer" then the bower_components dir will now contain directories >>>>>>>> for >>>>>>>> both polymer and polymer-polymer. So you might end up with elements >>>>>>>> importing the same libraries from different locations. >>>>>>>> >>>>>>>> I'm wondering if we should have one consistent way of doing (and >>>>>>>> documenting) everything? >>>>>>>> >>>>>>> Follow Polymer on Google+: plus.google.com/107187849809354688692 >>>>>>> --- >>>>>>> You received this message because you are subscribed to the Google >>>>>>> Groups "Polymer" group. >>>>>>> To unsubscribe from this group and stop receiving emails from it, >>>>>>> send an email to [email protected]. >>>>>>> To view this discussion on the web visit >>>>>>> https://groups.google.com/d/msgid/polymer-dev/1154107e-afb1-4a7f-85ca-f405fb1725d4%40googlegroups.com >>>>>>> . >>>>>>> >>>>>>> For more options, visit https://groups.google.com/groups/opt_out. >>>>>>> >>>>>> >>>>>> Follow Polymer on Google+: plus.google.com/107187849809354688692 >>>>>> --- >>>>>> You received this message because you are subscribed to the Google >>>>>> Groups "Polymer" group. >>>>>> To unsubscribe from this group and stop receiving emails from it, >>>>>> send an email to [email protected]. >>>>>> To view this discussion on the web visit >>>>>> https://groups.google.com/d/msgid/polymer-dev/CAHbmOLaCe-wcFFWa_Sxayq4rNsAeGWPDfn1MOm-%2B%2BS%2By6FLyaQ%40mail.gmail.com >>>>>> . >>>>>> >>>>>> For more options, visit https://groups.google.com/groups/opt_out. >>>>>> >>>>> >>>>> >>>> >>> >> > Follow Polymer on Google+: plus.google.com/107187849809354688692 --- You received this message because you are subscribed to the Google Groups "Polymer" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/polymer-dev/CAHbmOLY-HZuGkymaChynHO3VfjFwWhDnyF1GDOm5Av25hwQyEA%40mail.gmail.com. For more options, visit https://groups.google.com/groups/opt_out.
