> > 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. 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/CAJj5OwAz0q%3DpW5HDVvEVH9vGGTqU72AxMEOyp0kOXPj5hVw%3DcA%40mail.gmail.com. For more options, visit https://groups.google.com/groups/opt_out.
