bower packages

[Rob Dodson]

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?

[Marcin Warpechowski]

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.

[Scott Miles]

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

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 polymer-dev...@googlegroups.com.

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.

[Rob Dodson]

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 

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.

[Steve Orvell]

You can end up with multiple directories for the same stuff.

How?

It feels "un-bower" like to force people to use Owner/Repo syntax.

Perhaps this suggests bower is not the right tool then.

To view this discussion on the web visit https://groups.google.com/d/msgid/polymer-dev/CAJj5OwCTLayyaS9Yu06n6FxWK2NvPx9idvVP_X3wpiY9wAmKKA%40mail.gmail.com.

[Scott Miles]

>> 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 <robd...@google.com> wrote:

[Rob Dodson]

You can end up with multiple directories for the same stuff.

How?

bower install polymer-platform

bower install polymer

bower install polymer-polymer

In your bower_components you'll now have folders for polymer, platform, polymer-platform, and polymer-polymer. Because polymer's bower.json file depends on "Polymer/platform" bower creates a new directory just using the repo name. I believe this could lead to a scenario where Component A links to ../polymer and Component B links to ../polymer-polymer.

[Eric Bidelman]

My $0.02: I care more about preventing confusion than the command we recommend. The main thing is be consistent. 

My impression is that most people don't know the "Polymer/xyx" shorthand (I didn't), but they'll use whatever ends up in our docs. The confusing bit is having 3 different ways to get Polymer atm:

1. bower install polymer

2. bower install polymer-polymer

3. bower install Polymer/polymer

The same decision applies to Platform :/.  There's a redundancy in having both #1 and #2 as official packages we publish. What do we think about consolidating #1 and #2?

IMO, if we're doing the work of maintaining packages, we should recommend them. Obviously a huge benefit is discoverability, but the other is that's how most people know, interact, and used Bower in 2013. We'll see what the rest of this year brings.

On Tue, Feb 25, 2014 at 8:42 PM, Rob Dodson <robd...@google.com> wrote:

You can end up with multiple directories for the same stuff.

How?

bower install polymer-platform

bower install polymer

bower install polymer-polymer

In your bower_components you'll now have folders for polymer, platform, polymer-platform, and polymer-polymer. Because polymer's bower.json file depends on "Polymer/platform" bower creates a new directory just using the repo name. I believe this could lead to a scenario where Component A links to ../polymer and Component B links to ../polymer-polymer.

On Tue, Feb 25, 2014 at 8:08 PM, Steve Orvell <sor...@google.com> wrote:

You can end up with multiple directories for the same stuff.

How?

It feels "un-bower" like to force people to use Owner/Repo syntax.

Perhaps this suggests bower is not the right tool then.

No forcing, just prescription :) If a better tool comes along in 2H 2014, we can evaluate it. This project will continue to lose quarters of blood as we bleed on the edge!

 

To view this discussion on the web visit https://groups.google.com/d/msgid/polymer-dev/CAJj5OwDd7n52spoEhyaUXnhu-dG9dSdH_x2UWh6p0i%3DXJ0q7Xg%40mail.gmail.com.

[Rob Dodson]

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.

[Scott Miles]

Polymer engineering has never said anything but this: "use <Org>/<Repo>".  I expressly asked our team not to publish to Bower registry for all the reasons I already gave.

>> 

1. bower install polymer

2. bower install polymer-polymer

3. bower install Polymer/polymer

<<

I don't have any clue what 2 refers to. Rob also referred to `polymer-platform` and `polymer-polymer`. I have no idea where those came from either. 

>> [Rob] bower.json file depends on "Polymer/platform" bower creates a new directory just using the repo name

No, our bower.json entries look like this:

"platform": "Polymer/platform"

The folder name is on the left, the repo name is not used.

[Scott Miles]

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.

[Rob Dodson]

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.

[Scott Miles]

On Tue, Feb 25, 2014 at 10:30 PM, Rob Dodson <robd...@google.com> 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).

[Rob Dodson]

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 :)

[Scott Miles]

Seems like we agree that Bower is not there yet. =P

To view this discussion on the web visit https://groups.google.com/d/msgid/polymer-dev/CAJj5OwBL-mbdgZ954eGFtPcqvva8H1tfKfEGnx9t284NJx8hBQ%40mail.gmail.com.

[Brian Di Palma]

I agree with Scott on the short comings of npm\bower.

I have raised an issue on npm about the name `node_modules` but it seems that there will be no other name considered. Even to a fixed, generic, neutral one.
There is also a need for some namespacing, as Scott was suggesting an organization one would make sense and should be enough for most, if not all, cases.
I was thinking of suggesting that to npm; I didn't realise/think that bower already had something like that, a pro to bower imo.

Still, given all those issues package managers/depedency managers are part of normal future web development and that will only acclerate with ES6 modules around the corner.

They are not perfect tools but their pros outweight their cons so their use will keep increasing, therefore it seems a good idea for libraries to be available via these tools.

[Rob Dodson]

I asked Mat Scales about the pros/cons of Owner/Repo syntax vs registry. Much of it we've covered here already:

Owner/Repo pattern:

- Avoids a lookup on the registry, removing a point of failure/possibly slowness.

- Allows namespacing

- Automatic for anything on Github, no need to manage registry entries

Registered name:

- Shorter to remember

- Can move the repo without users noticing

- Not tied to Github

- Discoverability through the registry search (which will only get better)

I would also add, as Eric pointed out, most people have used bower with registered name style so there's an established convention with supporting blog posts.

As Eric pointed out, we need to be consistent in whatever we do. If we decide to go with Owner/Repo syntax then the site should be updated to only use that style. I'm worried that when a developer asks "Why didn't you register your packages" and I respond "We didn't want to be locked into a registry" that it will encourage them to also not register their packages. Is that what we want?