support for repos other than GitHub

[Patrick Mueller]

First of all, awesome.  Love to see folks playing with new angles on this.

Based on my experience with node/npm, I'd like to see the following capabilities for specifying a "repo" for a component:

- in the component.json, I should be able to specify a repo per component; I will likely want to pull some components from GitHub, but others from a private or otherwise different repo.  

- in some cases, I'm developing multiple packages (npm) (now components) at the same time.  npm provides "link" capabilities so I can cross-link dependencies, but this isn't great.  Since dependencies aren't bundled (I don't think) when you download them from a repo, I think the most straight-forward thing to do in this case is to allow me to stub out a component with a pointer to what I want to use at development time.

re: first point - howsabout the current key in the dependencies object be a URL instead of a :user/:repo string?  The default, scheme-less URL, could continue to point to GitHub, but if I used "my-repo://foo-blatz": <some-version-string>, then that would mean "resolve using the my-repo" repo handler.  You would of course have to have a repo handler installed in some fashion (and then here comes the chicken-and-egg question :-) ).  Would also need to figure out what this means with this gnarly mess of aliasing that's going on - I think at runtime you don't want to see the repo's, just more of a :something-:something-else scheme.

re: second point - the example here would be that I'm developing an app that uses a component which I would also like to publish as an consumable component.  Say, I'm developing App A that uses Component B, and I also want to publish Component B for other people to use in their own apps.  

npm solves this with "npm link", but it's a bit of a pain to set up.  In the example case, what I'd like to do is structure my source code like this:

project/

- app.A

- component.B

where app.A and component.B are both components (both use component.json to access other components).  In this case, app.A needs a reference to component.B.  I would expect app.A's component.json to look something like this:

    dependencies: {

        ...

        "myRepo://component.B": "*",

        ...

    }

But I don't really want to "install", at development time, component.B in app.A/component.  What I really want is a "link".  I think I'd prefer some kind of actual file, instead of file system link.  So, say, I create a directory "linked-dependencies", and in there I plop a file "component.B", in some kind of resolvable name, which has a file reference to the actual component.  In this case, it would be "../component.B".  Then whenever some code tries to resolve "component.B" - at "component install"time AND at build time / run time, it's resolved as the linked-to directory.

[vision media [ Tj Holowaychuk ]]

IMO a decent way to go about it would justbe to specify that you have a dep of "foo/bar" you set up in ~/.component.json config that you want to check an internal "registry" first, so even regular deps like "component/tip" *could* resolve to your private fork if you liked, without change. To me this is cleaner than explicitly specifying entire repo urls 

--
You received this message because you are subscribed to the Google Groups "component" group.
To unsubscribe from this group, send email to componentjs...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

[Patrick Mueller]

On Thu, Sep 6, 2012 at 12:38 PM, vision media [ Tj Holowaychuk ] <t...@vision-media.ca> wrote:

IMO a decent way to go about it would justbe to specify that you have a dep of "foo/bar" you set up in ~/.component.json config that you want to check an internal "registry" first, so even regular deps like "component/tip" *could* resolve to your private fork if you liked, without change. To me this is cleaner than explicitly specifying entire repo urls 

I'd really like to indicate on the component dependency name, or value, the repo that should be accessed to retrieve the dependency.  I already know which components I want to get from which registry, and I don't really want to "accidently" pick up a dependency from the wrong repo.  Alternatively, a separate key in the component.json that mapped component names to registries:

    {

        "component-registries": {

            "foo/bar": "some://url/here/?version=:version"

        },

        "dependencies": {

            "foo/bar": "*"

        },

    }

Default registry being GitHub.

That would solve the issue of "mapping" some foreign component into the "component name space" (ie, :user-:repo) as well.

This could be in a separate side file in your project, I suppose, but that seems like overkill and the information is now shared across files, when it's nice to have all this info in one single place. "component install" would be groping around for this separate file all the time.

I like the idea of being able to have a component.json being fully self-describable, in terms of where to get it's dependencies from.  There may be some magic "dependency url resolver" which "obtains" components somehow, which you have to have installed in your project in order for the URL in the component.json to make sense.  

The problem with the current npm story in this regard is that you can only ever point to one repo - the default npmjs.org, or overridable via command-line/env-var.  This is problematic to get set up correctly for users.  Asking developers to "hand-install" (if it can't be automated) a foreign component resolver is much less of a problem.  Do it once, you're done, and you can keep this hand-installed resolver IN your development-time project's SCM.  No command-line/env-var madness.  No wondering WHICH repo you got a dependency from (in the case of a list/hierarchy of repos).

--
Patrick Mueller
http://muellerware.org

[vision media [ Tj Holowaychuk ]]

I like the idea of stating the registries in the main component.json rather than some ~/, I'll add that to the issue.

I don't think though that we really need to "map" to these registries, it's pretty east to have an app (https://github.com/component/server/blob/master/app.js) that serves up `/:user/:proj/:version` etc like github

[Patrick Mueller]

Thanks for noting that in https://github.com/component/component/issues/6 (for future reference for myself).

So, if all the repo access follows github "raw" naming conventions, I think all I'd want to do is supply you an http:// url prefix in front of :user/:proj/:version , or whatever.  My current thoughts are to store things not at GiHub on a plain old http file server, and so it should be straight-forward to publish in that way.  I was already planning on doing that with npm, using http:// urls as my dependencies.

I wonder if at some point, though, you're going to want to venture into Github API territory (starting here? - https://github.com/component/component/blob/master/lib/component.js ), in which case things get a little more complicated.  

On Thu, Sep 6, 2012 at 1:18 PM, vision media [ Tj Holowaychuk ] <t...@vision-media.ca> wrote:

I like the idea of stating the registries in the main component.json rather than some ~/, I'll add that to the issue.

I don't think though that we really need to "map" to these registries, it's pretty east to have an app (https://github.com/component/server/blob/master/app.js) that serves up `/:user/:proj/:version` etc like github

 

[vision media [ Tj Holowaychuk ]]

eventually we might use github's API for some things, for example sniffing out projects that have a component.json to populate our search, but that wouldn't have too much of an effect on private stuff

--