> > Bower does not have an analogous relationship to the Web (at least, not > yet =P).
Maybe not yet but someday... When you acquire Node you get npm right in the box. Those tools are welded > together. That wasn't always the case <http://howtonode.org/introduction-to-npm> :) On Tue, Feb 25, 2014 at 10:36 PM, Scott Miles <[email protected]> wrote: > 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/CAJj5OwBL-mbdgZ954eGFtPcqvva8H1tfKfEGnx9t284NJx8hBQ%40mail.gmail.com. For more options, visit https://groups.google.com/groups/opt_out.
