That's a really good point. It seems this particular package is the exception, not the rule, at least I hope so! I'll recommend a fix.
On Monday, March 25, 2013 7:29:49 PM UTC-7, Martin Cooper wrote: > > My own perspective is that relying on projects that declare their > dependencies this way is a really bad idea. They're relying on unreleased > versions of packages that aren't necessarily considered stable enough for > use by the package author in the first place. If the authors had considered > them stable, they would have published to the npm registry, since that > takes a matter of seconds. It's even worse when no commit is specified, > since the dependency is then a moving target, changing with every commit, > and you could be completely broken at any time. > > If your build servers are partially locked down for security reasons, I'd > think you'd want to have the security of knowing that you have reproducible > builds - that you'd get the same thing if you build the same project twice. > With dependencies like this, you don't have that. > > I fully realise that this isn't what you're asking, but I submit that this > is a bigger issue than just having npm futz around with the specified > protocols to see if it can find one that works. > > -- > Martin Cooper > > > On Mon, Mar 25, 2013 at 4:46 PM, Daniel Wabyick > <[email protected]<javascript:> > > wrote: > >> We have a build environment where our build servers do not have external >> SSH access for security reasons. We've got hit by the problem like in the >> following pull request [0], where an NPM dependency does not specify both >> the git+https protocol. >> >> [0] https://github.com/jsdoc3/jsdoc/pull/352/files >> >> Since this was a dependency of another project, we didn't really have an >> easy way to make this fix, and have to wait until it gets fixed in an NPM >> exposed repository. >> >> It seems like 'a good thing' if NPM either a) had a setting to allow git >> to imply git+https, or b) just always tried https if the git:// protocol >> failed. >> >> >> I'm interested in doing the work and making a pull request, but wanted to >> see if there was a downside to this approach that I'm missing. Personally, >> I would choose b) to keep settings to a minimum. >> >> >> >> -- >> -- >> Job Board: http://jobs.nodejs.org/ >> Posting guidelines: >> https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines >> You received this message because you are subscribed to the Google >> Groups "nodejs" group. >> To post to this group, send email to [email protected]<javascript:> >> To unsubscribe from this group, send email to >> [email protected] <javascript:> >> For more options, visit this group at >> http://groups.google.com/group/nodejs?hl=en?hl=en >> >> --- >> You received this message because you are subscribed to the Google Groups >> "nodejs" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to [email protected] <javascript:>. >> For more options, visit https://groups.google.com/groups/opt_out. >> >> >> > > -- -- Job Board: http://jobs.nodejs.org/ Posting guidelines: https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines You received this message because you are subscribed to the Google Groups "nodejs" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/nodejs?hl=en?hl=en --- You received this message because you are subscribed to the Google Groups "nodejs" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/groups/opt_out.
