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:
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.
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
On Thu, Sep 6, 2012 at 9:15 AM, Patrick Mueller <pmue...@gmail.com> wrote:
> 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:
> 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.
> --
> You received this message because you are subscribed to the Google Groups
> "component" group.
> To unsubscribe from this group, send email to
> componentjs+unsubscribe@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.
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:
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).
On Thu, Sep 6, 2012 at 10:05 AM, Patrick Mueller <pmue...@gmail.com> wrote:
> 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:
> 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).
> --
> You received this message because you are subscribed to the Google Groups
> "component" group.
> To unsubscribe from this group, send email to
> componentjs+unsubscribe@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.
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.
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
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
> 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.
> 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
> --
> You received this message because you are subscribed to the Google Groups
> "component" group.
> To unsubscribe from this group, send email to
> componentjs+unsubscribe@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.
