support for more endpoints like Gitlab and Github Enterprise

[sankargorthi]

Going off of the bitbucket implementation, support gitlab for component@1

See related issue on component(1).

[netpoetica]

I think one thing that will definitely be a point of contention is the fact that every gitlab remote is a different URL, i.e. bitbucket is always api.bitbucket.org, github is always raw.github or whatnot, but Gitlab will need to be configured via some .bashrc/.*rc file as an export. Something like

export COMPONENT_GITLAB_REMOTE='http://mycompany.com/gitlab/';

I wonder if it will be a struggle eventually for people who may have two or three different Gitlab remote URLs, or, even companies who are using two seperate Gitlab URLs (dev remotes vs. production remotes or something). I think it would be worth just working with the assumption there can only be one, and that users will have to specify the variable before calling component install if they want to use one of many remotes. ie

COMPONENT_GITLAB_REMOTE='https://secure.mycompany.com/repos'
component install

Keep me posted on what you've got going on - I will be available this weekend to help/review/pickup where you leave off, etc. Cheers!

[sankargorthi]

I liked the old model where you would provide an array of remotes and then assume that component automatically adds github.com as a default remote.

Is that not possible with component@1?

[timaschew]

We had a similar discussion already. The Problem is that each new remote
endpoint will slow down the install process if you use mixed dependencies
from different endpoints.

So you need to map your deps to an endpoint with a special syntax like

depenendies: {
  "bitbucket:foo/bar": "1.2.1",
  "component/dom": "1.*",
  "customA:company/qux": "*"
}

I think there is no solution wihtout using the remotes API to realize
custom enfpoints. But that's a little bit overkill? Because you need to use
the builder, resolver and remotes API. Maybe we can do a mapping to the
implementation file within the components.json like

remotes: [
  {github: true}, // default
  {bitbucket: false}, // disable bitbucket lookup,
  {customA: "../company-gitlab-remote.js"}
]

So remotes become an array of objects. You can disable and reorder the
built-in remotes (github, bitbucket, locals)

Behaviour:
Deps without a remote identifier will be lookuped first on github. If the
was not found the next remote will be checked. Because bitbucket is
disabled the custom remote is the next one.
Deps with a remote identifier will be checked only for the given remote

[netpoetica]

I like the idea of a remote dictionary a lot, but I think it might warrant having a .componentrc file we look up in user folder (~) or moving this configuration to environment variables. I'm curious how the dependency chain will behave once you start having nested components with different remotes configurations - it seems like it may open the door to strange behavior.

component-1/
   - bitbucket: false, github: true
   dependency-component-1/
     - bitbucket: true, github: false, cutsomA: "mycoolstuff.xxx"
     depdendency-component-1/
        - bitbucket: false, github: true
     dependecy-component-2/
        - bitbucke: true, github: false

etc, etc. It actually leads to a good point that it may be important not to have a global config to ensure that dependencies use the remotes they actually need, and not the remotes that are configured by the user.

[timaschew]

to ensure that dependencies use the remotes they actually need, and not the remotes that are configured by the user.

Yes this would be very nice, but I think this is really hard to realize without define dependencies redundant and be backward compatible (to old component.json files). And solve all this problem from the beginning.

IMO we should focus in the very first solution to make it easier to add custom remote end points and give the user the control which remotes he need.
The default behaviour should be to that github and bitbucket is enabled.

The user can disable them (to boost the install process) if he knows that none of his dependencies (even transitive) use any of his disabled remotes. And if he disabled it accidently, he will notice it when he try to install the dependencies, he will get an error that a dependency could not be resolved. So I think this is not a problem.
But as I said, in the default case there is no problem.
If the user stil want to boost the install process, he can define the remote within the dependency like "bitbucket:foo/bar": "1.2.1". This just won't work for transitive dependencies, but this should be not the focus at the moment.

[graouts]

I like what timaschew is saying: "IMO we should focus in the very first solution to make it easier to add custom remote end points and give the user the control which remotes he need."

Could we list the dependencies as fully qualified URLs to the git repository that can then be cloned? Or would that be considered too verbose?

I also think a .componentrc config file for remotes would be adequate such that users could configure several github enterprise or gitlab endpoints.

[timaschew]

do you have another idea how to map the the dependencies inside component.json with the endpoints inside . componentrc ?

[graouts]

Thinking primarily of GitHub Enterprise here, since that's my primary concern, how about a github prefix when defining a GitHub Enterprise endpoint so that component knows it's dealing with GitHub install? Then additional handlers for GitLab could also support a gitlab prefix. I don't know if that makes much sense with regards to the remotes API.

remotes: {
    "ghe": "github:myGitHubInstall.myCompany.com"
}

Then the .componentrc would be something like:

Host myGitHubInstall.myCompany.com
User graouts