Bitbucket support

[stephenmathieson]

I use private bitbucket repos for business logic ('cause it's free ;)). The only reason I've moved from component@0 to component@1 is for built-in support. It'd be a bummer to have to go back to hosting a hacky proxy thing.

Would you guys be up for bitbucket support? If so, I can try to get something working soon-ish.

[matthewmueller]

yah, definitely down, just not a priority for me atm.

I'm in the process of a big refactor to hopefully clean up duo#dependencies(). But after that gets merged, you should definitely hack in bitbucket support :-)

[stephenmathieson]

awesome I'll see what I can do.

[stephenmathieson]

@yields im gonna write a quick module (bb-resolve, basically a mirror of gh-resolve) and am wondering what exactly were going to need from it. it looks like all duo-package uses is ref.name, which is good because the bitbucket api sucks..

@MatthewMueller are you cool with something like:

var ref = resolve_from_github()
if (!ref) resolve_from_bitbucket()
if (!ref) this.error('boom!')

or should hitting bitbucket only work behind some setting somewhere? idk if people want their installs slowed down by default

[yields]

sounds good for now -- for the future are we going to do something like require('bitbucket.org/some/repo') and then have a bunch of providers or whatever ?

[stephenmathieson]

hmm idk. would we always prefix require()s with a provider, or just for non-github repos?

[matthewmueller]

@yields im gonna write a quick module (bb-resolve, basically a mirror of gh-resolve) and am wondering what exactly were going to need from it. it looks like all duo-package uses is ref.name, which is good because the bitbucket api sucks..

Good idea!

@MatthewMueller are you cool with something like...

Hmm. I'd rather do something slightly more extendible (for other services), where we're not making a bunch of requests for bitbucket, private git server users. I like fallbacks (remotes: [...]) as a concept, but if we can minimize requests and keep them fast, that would be nice.

[matthewmueller]

I'm leaning towards @yields suggestion, but we'd need a component.json solution that's seamless - maybe just { "bitbucket.org/some/repo": "*" }

[yields]

Hmm. I'd rather do something slightly more extendible (for other services), where we're not making a bunch of requests for bitbucket, private git server users. I like fallbacks (remotes: [...]) as a concept, but if we can minimize requests and keep them fast, that would be nice.

+1 actually yeah, in the end if we do fallbacks people who actually use them will see the slowness, so maybe it will be better to prefix...

BitBucket

duo.provider(/^bitbucket\.org:([\w\/]+)$/, function(m){
  // resolve
  // request
  // return a stream?
});

Github

duo.provider(/^(github\.com:)?([\w\/]+)$/, function(m){
  // resolve
  // request
  // return a stream?
});

and then duo handles unpacking/bundling ?

[stephenmathieson]

+1 on duo.provider.

i assume no provider will always default to github?

also, return a stream? a stream of all resolved files, or ... ?

[yields]

also, return a stream? a stream of all resolved files, or ... ?

no clue haha, that's the hard part, i guess ideally a tar stream.

[matthewmueller]

so, i'm seeing duo-package change it's resolve and fetch based on the provider:

Package('component/emitter', '*')
  .provider('bitbucket')

We might need to do what @yields suggested with /^bitbucket\.org:([\w\/]+)$/ to keep things extendable, but it'd be nice to do something like:

Package.provider(require('duo-bitbucket')());

And have it all self-contained.

p.s. just spitballing ideas. not sure what the api would look like yet.

[matthewmueller]

duo-bitbucket could maybe export a few functions like... resolve & fetch

[yields]

duo-bitbucket could maybe export a few functions like... resolve & fetch

+1.

to do this i suppose we should move all github logic from duo-package and put it in duo-github and then use it by default, just to make things more modular.

[matthewmueller]

to do this i suppose we should move all github logic from duo-package and put it in duo-github and then use it by default, just to make things more modular.

+1 agreed and just have it be the default

[matthewmueller]

getting on flight, chat later!

[stephenmathieson]

yep, +1 for duo-{github,bitbucket}.

can it export something like:

exports.expr = /^(github\.com:)?([\w\/]+)$/

exports.resolve = function(){
  return ghresolve()
}

exports.fetch = function(){
  return getamagicstream()
}

[jonathanong]

how do you detect whether a repo uses mercurial or git? tempted to just never support mercurial. heh

[stephenmathieson]

just never support mercurial

+1

bitbucket doesn't care anyway. if were going down the tarball route, you just https://bitbucket.org/user/repo/get/x.y.z.tar.gz for either git or mercurial