All:


I have been experimenting with volo (http://volojs.org) with
dependency/package management for Dojo in light of Dojo 2.0. For those not
familiar, volo is a toolset for managing/building websites from James
Burke. The biggest benefit is that it is an AMD aware package "manager"
that builds upon the CommonJS package definition to provide easy discovery
and installation of packages, along with managing the dependencies of those
packages.


The changes for us would be minimal, essentially adding a couple lines to
our package.json of our main packages. End users could very easily add
their dependencies to their projects and then volo will do the rest of the
work. I have converted over my experimental documentation wiki to leverage
volo to manage it's dependencies on Dojo:
https://github.com/kitsonk/dojoment/blob/master/package.json. I also
experimented by modifying the package.json in my personal forks of
dojo<https://github.com/kitsonk/dojo>,
dijit <https://github.com/kitsonk/dijit> and
dojox<https://github.com/kitsonk/dojox>to include the volo information
to be fully consumable by volo.


While Kris did well with cpm, I really found volo easy to use and its
automatic integration with GitHub makes it very easy for end developers not
only consume Dojo easily, but also other packages and libraries. There are
also other parts of volo that I have yet to explore or experiment with that
might make the whole toolchain of "building" Dojo and websites a little bit
easier to end developer, which is good for everyone.


I am sure James can give us his opinion on volo and the suitability of us
adopting it as our standard and any part of volo we might be missing that
would be useful for us to take a look at.


The one thing I think we would want to do is continue/develop the package
registry at http://packages.dojofoundation.org/ in order to continue to
grow the community.


I am throughly impressed with volo. Its simplicity and elegance are not
lost on me. Consider that even if we did nothing, you can right now add
Dojo to your project with the following:


volo add dojo/dojo
volo add dojo/dijit
volo add dojo/dojox




Let's say you don't want 1.8.0, you want the latest version of 1.7:


volo add dojo/dojo/~1.7
volo add dojo/dijit/~1.7
volo add dojo/dojox/~1.7




How wonderful is that? Let's say you have a project where you have already
identified all your volo dependencies in your package.json, just give this
a go:


volo add




Anyways, I will be prepared to talk about this more at the weekly meeting.


Regards,
Kit
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.dojotoolkit.org/pipermail/dojo-contributors/attachments/20120918/b0f62790/attachment.htm

Search Discussions

  • James Burke at Sep 19, 2012 at 3:27 pm
    I cannot make the meeting today, but here is some background on volo,
    and what else is currently in the landscape:


    Some key design goals in volo:


    * Go where the people already are. To me, this is GitHub. The benefit
    is that GitHub already has an auth system and social feedback tools.
    It is already a part of many JS developer's toolchain.
    * Allow people to publish distributions outside of GitHub. This is
    what the volo.url support in a package.json is about [1].
    * Allow pulling down single JS file dependencies.
    * Has a "shim" repo where just package.json diffs for volo are kept,
    which allows using existing libraries without needing them to push
    their code to a repo of my choosing [2].
    * AMD aware, but does not mandate AMD usage. Also does not include a
    specific AMD loader, instead assumes project templates will include
    one if it wants.


    Reasons I did not just use npm: https://github.com/volojs/volo/wiki


    volo weaknesses:


    * No "private repo" support at the moment, so a company cannot run its
    own internal repo of code. Although I think that is fixable via
    allowing other dependency protocol types. volo supports fetching code
    via other protocols (http:, https:), but the default one used if none
    specified is github:. I would like to support at least one other, for
    companies that want to run a private repo. Maybe that is cpr, maybe
    that is something like the jamjs repo.


    * It relies on github search to find things, so it may not be
    tuned/controllable precisely to what is needed. It is easy to specific
    by using "owner/repoName" dependency IDs though.


    Some other efforts in this space, besides cpm+cpr:


    jamjs [3]
    --------


    Has its own standalone repo, similar to the one used by npm, but
    installs things in an AMD-friendly way, using requirejs as part of
    hooking up the installed pieces to a runtime config. It means stamping
    a config file for each dependency installed.


    Interesting because it is AMD aware, has some pickup. May be possible
    to allow specifying another AMD loader, particularly if we all support
    common config values, like baseUrl, paths and maybe map.


    bower [4]
    ---------


    Used by yeoman, for yeoman's package manager. Has its own standalone
    repo which is git-based, but not GitHub. Seems to be able to leverage
    a bootstrap mechanism by looking in the https://github.com/components
    group but not clear about that.


    It likes to install dependencies in a directory with a component.json
    and index.js as the dependency name. So, for 'jquery', it would be
    loaded from a 'jquery/index.js'. I find this part awful. It should be
    possible to install single JS file dependencies just as just the .js
    file.


    component [5]
    ---------------


    Uses github for repo, but wants to have everything in CommonJS format
    and does builds. Uses component.json instead of package.json. Uses a
    github wiki for finding things via its search. Seems more for folks
    that come from node. Seems more complicated that it needs to be for
    dependency references, but complication in this space is definitely in
    the eye of the beholder.


    James


    [1] https://github.com/volojs/volo/wiki/Library-best-practices#wiki-minimizinggithub
    [2] https://github.com/volojs/repos
    [3] http://jamjs.org/
    [4] https://github.com/twitter/bower
    [5] https://github.com/component/component

    On Tue, Sep 18, 2012 at 12:57 PM, Kitson Kelly wrote:
    All:

    I have been experimenting with volo (http://volojs.org) with
    dependency/package management for Dojo in light of Dojo 2.0. For those not
    familiar, volo is a toolset for managing/building websites from James Burke.
    The biggest benefit is that it is an AMD aware package "manager" that builds
    upon the CommonJS package definition to provide easy discovery and
    installation of packages, along with managing the dependencies of those
    packages.
  • Kitson Kelly at Sep 22, 2012 at 2:09 am
    All:


    During the weekly meeting after some conversation regarding volo and in
    particular cpm and npm, I agreed to start a discussion document that had a
    bit more meat to it in order to figure out where we go in Dojo 2.0 with
    package management and other tooling. I have completed a draft of that
    here: Dojo Toolkit 2.0 Package
    Management<https://docs.google.com/a/kitsonkelly.com/document/d/1lwiYQQharkqWmxeOU4QUpZfEToEkZR0ecRWo68Vbwpo/edit>
    .


    In my estimation at the moment, there is no clear "winner" between cpm and
    volo. Either we need to enhance cpm or adopt volo and potentially suggest
    bending it a little bit. Either way, I think there is enough there now to
    have a more substantive conversation at the meeting next week.


    Of course the document is my opinion only at the moment and if there are
    others who feel they can contribute to it, feel free to contact me and I
    will give you edit rights or feel free to give me feedback, either through
    the ML or directly and I can update the document. In particular, James and
    Kris, I wouldn't mind making sure I have been accurate with volo and cpm.


    Regards,
    Kit


    On 18 September 2012 20:57, Kitson Kelly wrote:

    All:

    I have been experimenting with volo (http://volojs.org) with
    dependency/package management for Dojo in light of Dojo 2.0. For those not
    familiar, volo is a toolset for managing/building websites from James
    Burke. The biggest benefit is that it is an AMD aware package "manager"
    that builds upon the CommonJS package definition to provide easy discovery
    and installation of packages, along with managing the dependencies of those
    packages.
    -------------- next part --------------
    An HTML attachment was scrubbed...
    URL: http://mail.dojotoolkit.org/pipermail/dojo-contributors/attachments/20120922/3f736b69/attachment.htm
    -------------- next part --------------
    A non-text attachment was scrubbed...
    Name: Dojo Toolkit 2.0 Package Management.gdoc
    Type: application/octet-stream
    Size: 185 bytes
    Desc: not available
    Url : http://mail.dojotoolkit.org/pipermail/dojo-contributors/attachments/20120922/3f736b69/attachment.dll
  • Colin Snover at Sep 22, 2012 at 11:32 am
    That document can't be viewed without permission and the link goes to a
    Google Apps hosted account. Interested to see it once I can :)

    On 2012-09-22 01:09, Kitson Kelly wrote:
    All:

    During the weekly meeting after some conversation regarding volo and
    in particular cpm and npm, I agreed to start a discussion document
    that had a bit more meat to it in order to figure out where we go in
    Dojo 2.0 with package management and other tooling. I have completed
    a draft of that here: Dojo Toolkit 2.0 Package Management
    <https://docs.google.com/a/kitsonkelly.com/document/d/1lwiYQQharkqWmxeOU4QUpZfEToEkZR0ecRWo68Vbwpo/edit>.

    In my estimation at the moment, there is no clear "winner" between cpm
    and volo. Either we need to enhance cpm or adopt volo and potentially
    suggest bending it a little bit. Either way, I think there is enough
    there now to have a more substantive conversation at the meeting next
    week.

    Of course the document is my opinion only at the moment and if there
    are others who feel they can contribute to it, feel free to contact me
    and I will give you edit rights or feel free to give me feedback,
    either through the ML or directly and I can update the document. In
    particular, James and Kris, I wouldn't mind making sure I have been
    accurate with volo and cpm.

    Regards,
    Kit

    On 18 September 2012 20:57, Kitson Kelly <me at kitsonkelly.com
    wrote:

    All:

    I have been experimenting with volo (http://volojs.org) with
    dependency/package management for Dojo in light of Dojo 2.0. For
    those not familiar, volo is a toolset for managing/building
    websites from James Burke. The biggest benefit is that it is an
    AMD aware package "manager" that builds upon the CommonJS package
    definition to provide easy discovery and installation of packages,
    along with managing the dependencies of those packages.



    _______________________________________________
    dojo-contributors mailing list
    dojo-contributors at mail.dojotoolkit.org
    http://mail.dojotoolkit.org/mailman/listinfo/dojo-contributors



    --
    Colin Snover
    http://zetafleet.com


    -------------- next part --------------
    An HTML attachment was scrubbed...
    URL: http://mail.dojotoolkit.org/pipermail/dojo-contributors/attachments/20120922/e1224789/attachment.htm
  • Kitson Kelly at Sep 22, 2012 at 12:39 pm
    Sorry, still getting used to permissions on Google Docs. I thought it was
    shared with everyone, but it turned out it was shared with everyone who is
    on my domain, which of course is only me (unless of course you want a trend
    GMail account @kitsonkelly.com, all the cool kids are getting them).


    On 22 September 2012 16:32, Colin Snover wrote:

    That document can?t be viewed without permission and the link goes to a
    Google Apps hosted account. Interested to see it once I can :)

    -------------- next part --------------
    An HTML attachment was scrubbed...
    URL: http://mail.dojotoolkit.org/pipermail/dojo-contributors/attachments/20120922/0ef4345e/attachment.htm
  • Rawld Gill at Sep 23, 2012 at 10:56 am

    From: Kitson Kelly
    I have completed a draft of that here: Dojo
    Toolkit 2.0 Package Management
    <https://docs.google.com/a/kitsonkelly.com/document/d/1lwiYQQharkqWmxe
    OU4QUpZfEToEkZR0ecRWo68Vbwpo/edit> .

    In my estimation at the moment, there is no clear "winner" between cpm and
    volo. Either we need to enhance cpm or adopt volo and potentially suggest
    bending it a little bit. Either way, I think there is enough there now to have a
    more substantive conversation at the meeting next week.

    After your point-by-point comparison, you say nothing more about NPM. Why?


    Can you explain the semantics of the item "How does it deal with AMD?"


    It seems to me that another possible option is to develop an extension (not branch) to NPM that adds the functionality we need. I think NPM is fairly stable and likely used more than all the other javascript package managers combined. These two facts are quite important from a marketing pov.


    --Rawld
  • Kitson Kelly at Sep 23, 2012 at 12:08 pm
    I didn't speak about it further, because in my estimation it wasn't viable,
    especially compared with the other two options. In particular, these are
    the things I didn't like about npm and why I didn't think it warranted
    further consideration, in no particular order:


    - The npm registry is wholly independent of GitHub and requires a
    registry in order to find packages, and is clearly geared towards serving
    NodeJS. We would either have to integrate every package into the "NodeJS
    registry" (although they wouldn't be NodeJs modules) or create a separate
    registry and get everyone to "re-point" at that.
    - npm by default installs packages in ways that are geared towards
    server side frameworks and resolution of modules for NodeJS. For example
    in most cases "npm install module" would put it into "node_modules" of the
    root directory. That alone would be confusing to end developers. There
    are ways to remap it, but publishing AMD packages I think is somewhat
    problematic, although IIRC it was James Burke who was stating that he had
    struggled with it for an extended period of time, which is eventually what
    gave rise to volo in part.
    - I am not impressed with the care, maintenance and governance that npm
    and the associated website is given. Issue
    #116<https://github.com/isaacs/npm-www/issues/119>shows a level of
    personal frustration I have, and I recently have been
    having significant issues with even getting on to npmjs.org recently.
    - Its governance isn't fully clear in my mind, and seemed to be slightly
    less "open" than we maybe accustomed to, although I am not really in a
    position to comment on this, it was only what I could glean. In particular
    I couldn't easily figure out how contributions are made (simply pull
    requests, maybe to the GitHub repo) and it seems that it is wholly managed
    by Isaac. Where as with the other two, we understand their governance
    models and in particular, I noticed that James has gone out of his way to
    make it clear. (As a side note, I think it is becoming increasingly
    important for us to remind people that just choosing an open source license
    doesn't make your software open)
    - NodeJS (and CommonJS) for whatever reason have "rejected" AMD. It is
    likely that there will be further divergence in the future. My estimation
    is that npm will, by its nature, do whatever NodeJS does. If there is
    further divergence between AMD and NodeJS modules, we will be left out in
    the cold. My estimation is this risk is less with volo, because it is
    obviously committed to support AMD.


    I honestly don't know if an extension would be viable or not, but if it
    were, we would have to say "what you need to do is install npm, then
    install our extension and then you can finally install Dojo". Of course we
    could derive a single installable, but I don't necessarily see how that
    would be different from a fork as likely any upstream changes in npm would
    have a negative effect on the extension.


    But in the end, it is a discussion document. All I could add to it was my
    point of view. If we really feel that npm is a viable option, then I am
    all for discussing it. You are right that the penetration will
    significantly greater, but npm isn't a JavaScript package manager, it is a
    NodeJS Package Manager, and I think it will always be. If we feel my
    points above aren't valid (or not material to the decision) then I can
    further investigate what we would need to do in order to bend npm to our
    will. I just didn't think there was enough juice in the squeeze.


    On 23 September 2012 15:56, Rawld Gill wrote:

    After your point-by-point comparison, you say nothing more about NPM. Why?

    Can you explain the semantics of the item "How does it deal with AMD?"

    It seems to me that another possible option is to develop an extension
    (not branch) to NPM that adds the functionality we need. I think NPM is
    fairly stable and likely used more than all the other javascript package
    managers combined. These two facts are quite important from a marketing pov.

    --Rawld
    -------------- next part --------------
    An HTML attachment was scrubbed...
    URL: http://mail.dojotoolkit.org/pipermail/dojo-contributors/attachments/20120923/2210174b/attachment.htm
  • Tom Trenka at Sep 23, 2012 at 12:24 pm
    I'd also like to remind everyone that even though we are transitioning our
    utility tools to NodeJS, not everyone using Dojo does it in conjunction
    with NodeJS; there are scores of developers working off Java-based tools
    that use Dojo, as well as PHP and god knows what else.


    I think it's fine to require people to use Node for our utility tools, but
    IMHO I think trying to integrate a package installer direct with it is not
    viable either.


    My 2 cents--
    Tom


    On Sun, Sep 23, 2012 at 11:08 AM, Kitson Kelly wrote:

    I didn't speak about it further, because in my estimation it wasn't
    viable, especially compared with the other two options. In particular,
    these are the things I didn't like about npm and why I didn't think it
    warranted further consideration, in no particular order:

    - The npm registry is wholly independent of GitHub and requires a
    registry in order to find packages, and is clearly geared towards serving
    NodeJS. We would either have to integrate every package into the "NodeJS
    registry" (although they wouldn't be NodeJs modules) or create a separate
    registry and get everyone to "re-point" at that.
    - npm by default installs packages in ways that are geared towards
    server side frameworks and resolution of modules for NodeJS. For example
    in most cases "npm install module" would put it into "node_modules" of the
    root directory. That alone would be confusing to end developers. There
    are ways to remap it, but publishing AMD packages I think is somewhat
    problematic, although IIRC it was James Burke who was stating that he had
    struggled with it for an extended period of time, which is eventually what
    gave rise to volo in part.
    - I am not impressed with the care, maintenance and governance that
    npm and the associated website is given. Issue #116<https://github.com/isaacs/npm-www/issues/119>shows a level of personal frustration I have, and I recently have been
    having significant issues with even getting on to npmjs.org recently.
    - Its governance isn't fully clear in my mind, and seemed to be
    slightly less "open" than we maybe accustomed to, although I am not really
    in a position to comment on this, it was only what I could glean. In
    particular I couldn't easily figure out how contributions are made (simply
    pull requests, maybe to the GitHub repo) and it seems that it is wholly
    managed by Isaac. Where as with the other two, we understand their
    governance models and in particular, I noticed that James has gone out of
    his way to make it clear. (As a side note, I think it is becoming
    increasingly important for us to remind people that just choosing an open
    source license doesn't make your software open)
    - NodeJS (and CommonJS) for whatever reason have "rejected" AMD. It
    is likely that there will be further divergence in the future. My
    estimation is that npm will, by its nature, do whatever NodeJS does. If
    there is further divergence between AMD and NodeJS modules, we will be left
    out in the cold. My estimation is this risk is less with volo, because it
    is obviously committed to support AMD.

    I honestly don't know if an extension would be viable or not, but if it
    were, we would have to say "what you need to do is install npm, then
    install our extension and then you can finally install Dojo". Of course we
    could derive a single installable, but I don't necessarily see how that
    would be different from a fork as likely any upstream changes in npm would
    have a negative effect on the extension.

    But in the end, it is a discussion document. All I could add to it was my
    point of view. If we really feel that npm is a viable option, then I am
    all for discussing it. You are right that the penetration will
    significantly greater, but npm isn't a JavaScript package manager, it is a
    NodeJS Package Manager, and I think it will always be. If we feel my
    points above aren't valid (or not material to the decision) then I can
    further investigate what we would need to do in order to bend npm to our
    will. I just didn't think there was enough juice in the squeeze.
    On 23 September 2012 15:56, Rawld Gill wrote:


    After your point-by-point comparison, you say nothing more about NPM. Why?

    Can you explain the semantics of the item "How does it deal with AMD?"

    It seems to me that another possible option is to develop an extension
    (not branch) to NPM that adds the functionality we need. I think NPM is
    fairly stable and likely used more than all the other javascript package
    managers combined. These two facts are quite important from a marketing pov.

    --Rawld
    _______________________________________________
    dojo-contributors mailing list
    dojo-contributors at mail.dojotoolkit.org
    http://mail.dojotoolkit.org/mailman/listinfo/dojo-contributors
    -------------- next part --------------
    An HTML attachment was scrubbed...
    URL: http://mail.dojotoolkit.org/pipermail/dojo-contributors/attachments/20120923/3cf1f30d/attachment.htm
  • Rawld Gill at Sep 23, 2012 at 1:13 pm
    -----
    Tom Trenka


    I'd also like to remind everyone that even though we are transitioning our
    utility tools to NodeJS, not everyone using Dojo does it in conjunction with
    NodeJS; there are scores of developers working off Java-based tools that use
    Dojo, as well as PHP and god knows what else.

    I think it's fine to require people to use Node for our utility tools, but IMHO I
    think trying to integrate a package installer direct with it is not viable either.

    Right. And, according to Kit's document Volo requires node and NPM. So, if your assertion of no dependency on node is a requirement, then Volo is disqualified. (CPM just needs a trivial install script for windows.)


    iiuc, CPM uses Java. So either way, these things can't be pure JS.


    I see and respect your point. I'm just not sure I agree that Java is any less toxic than Node...particularly since they (Node) appear to be supporting windows these days. But, this is likely a religious argument.


    --Rawld
  • Tom Trenka at Sep 23, 2012 at 5:11 pm

    Right. And, according to Kit's document Volo requires node and NPM. So,
    if your assertion of no dependency on node is a requirement, then Volo is
    disqualified. (CPM just needs a trivial install script for windows.)

    iiuc, CPM uses Java. So either way, these things can't be pure JS.

    I see and respect your point. I'm just not sure I agree that Java is any
    less toxic than Node...particularly since they (Node) appear to be
    supporting windows these days. But, this is likely a religious argument.
    I agree; all I'm pointing out is that tying our package system to a
    particular platform might seem like we are advocating development under
    that platform to the exclusion of others. While it does seem like Node is
    where most of our server-side tools are heading, I just don't want users of
    Dojo that don't develop under Node to feel "left out in the cold".


    -- Tom
    -------------- next part --------------
    An HTML attachment was scrubbed...
    URL: http://mail.dojotoolkit.org/pipermail/dojo-contributors/attachments/20120923/8da81b45/attachment.htm
  • Kenneth G. Franqueiro at Sep 23, 2012 at 7:04 pm
    Either way, we'll be relying on a platform, and I agree with Rawld RE
    Java not being any less toxic than Node, so I'm not sure why Node is
    being singled out here. Currently our build system requires Java if you
    want minification (Closure and ShrinkSafe both require it), and this is
    a dependency I'd love to see us have the option of shedding, and I
    thought we were looking forward to allowing that to happen with UglifyJS
    for 2.0.


    While I guess we could look to support both Node.js and Rhino for
    everything, I'm not sure whether it's worth the effort, and I'd rather
    not strike modern tools from consideration just because they don't
    support Rhino.


    If you're going to be worried about conclusions that people may or may
    not jump to about what we're "seeming to advocate", I'd be far more
    worried of the appearance of being stuck 10 years in the past behind
    other JS libraries because we're still leaning on Java/Rhino. At the
    risk of sounding like one of 'em darned little whippersnappers who don't
    know what it's like to walk uphill in the snow both ways, I'd say 2.0 is
    our chance to get with the times already.


    --Ken

    On 9/23/2012 5:11 PM, Tom Trenka wrote:
    Right. And, according to Kit's document Volo requires node and NPM.
    So, if your assertion of no dependency on node is a requirement,
    then Volo is disqualified. (CPM just needs a trivial install script
    for windows.)

    iiuc, CPM uses Java. So either way, these things can't be pure JS.

    I see and respect your point. I'm just not sure I agree that Java is
    any less toxic than Node...particularly since they (Node) appear to
    be supporting windows these days. But, this is likely a religious
    argument.


    I agree; all I'm pointing out is that tying our package system to a
    particular platform might seem like we are advocating development under
    that platform to the exclusion of others. While it does seem like Node
    is where most of our server-side tools are heading, I just don't want
    users of Dojo that don't develop under Node to feel "left out in the cold".

    -- Tom


    _______________________________________________
    dojo-contributors mailing list
    dojo-contributors at mail.dojotoolkit.org
    http://mail.dojotoolkit.org/mailman/listinfo/dojo-contributors
  • Tom Trenka at Sep 23, 2012 at 8:36 pm
    My intentions here you mistake, young Skywalker, think I.


    NPM is a package manager that is aimed at a specific server-side platform
    (aka Node). To choose that as a way of distributing client-side, AMD,
    platform-neutral code would be, IMHO, a major mistake.


    I don't have a problem with us giving developers utilities that optimize
    and support the code that they are writing using a specific platform. All
    I'm counseling is that to try to integrate with something like NPM so
    directly would be a bad idea. At that point we'd consider just becoming
    part of Zend (no offense to Zend folks), or Tacos (look it up), or (insert
    server-side framework here).


    I'm also not advocating either way between Volo or CPM. Personally I like
    CPM (which I learned under Windows, right off the bat), and have not tried
    Volo--although having worked with James for many years, I would trust it
    because I trust the source of it. NPM though...the thought of using it to
    let people quickly and easily accomplish tasks--from the getgo, as in "I
    need a grid, dgrid looks nice, give it to me in a simple way without
    forcing me to go through basic .zip downloads and then go through a setup
    headache and a half--that gives me the shivers.


    -- Tom


    On Sun, Sep 23, 2012 at 6:04 PM, Kenneth G. Franqueiro
    wrote:

    Either way, we'll be relying on a platform, and I agree with Rawld RE
    Java not being any less toxic than Node, so I'm not sure why Node is
    being singled out here. Currently our build system requires Java if you
    want minification (Closure and ShrinkSafe both require it), and this is
    a dependency I'd love to see us have the option of shedding, and I
    thought we were looking forward to allowing that to happen with UglifyJS
    for 2.0.

    While I guess we could look to support both Node.js and Rhino for
    everything, I'm not sure whether it's worth the effort, and I'd rather
    not strike modern tools from consideration just because they don't
    support Rhino.

    If you're going to be worried about conclusions that people may or may
    not jump to about what we're "seeming to advocate", I'd be far more
    worried of the appearance of being stuck 10 years in the past behind
    other JS libraries because we're still leaning on Java/Rhino. At the
    risk of sounding like one of 'em darned little whippersnappers who don't
    know what it's like to walk uphill in the snow both ways, I'd say 2.0 is
    our chance to get with the times already.

    --Ken
    On 9/23/2012 5:11 PM, Tom Trenka wrote:
    Right. And, according to Kit's document Volo requires node and NPM.
    So, if your assertion of no dependency on node is a requirement,
    then Volo is disqualified. (CPM just needs a trivial install script
    for windows.)

    iiuc, CPM uses Java. So either way, these things can't be pure JS.

    I see and respect your point. I'm just not sure I agree that Java is
    any less toxic than Node...particularly since they (Node) appear to
    be supporting windows these days. But, this is likely a religious
    argument.


    I agree; all I'm pointing out is that tying our package system to a
    particular platform might seem like we are advocating development under
    that platform to the exclusion of others. While it does seem like Node
    is where most of our server-side tools are heading, I just don't want
    users of Dojo that don't develop under Node to feel "left out in the cold".
    -- Tom


    _______________________________________________
    dojo-contributors mailing list
    dojo-contributors at mail.dojotoolkit.org
    http://mail.dojotoolkit.org/mailman/listinfo/dojo-contributors
    _______________________________________________
    dojo-contributors mailing list
    dojo-contributors at mail.dojotoolkit.org
    http://mail.dojotoolkit.org/mailman/listinfo/dojo-contributors
    -------------- next part --------------
    An HTML attachment was scrubbed...
    URL: http://mail.dojotoolkit.org/pipermail/dojo-contributors/attachments/20120923/65f50c39/attachment-0001.htm
  • Kenneth G. Franqueiro at Sep 23, 2012 at 8:42 pm
    Thanks for clearing that up, I totally didn't gather that from your
    previous mails.


    It seems like you and Rawld both have reasons for being against the NPM
    path, and at this point I don't think it's the greatest idea either,
    although I was initially one of the people to bring it up. In
    particular, I am *definitely* against us "polluting" the NPM registry
    itself with non-node packages, and that wasn't what I had in mind. I
    was mostly interested to see if we could leverage any tools that already
    exist but use our own repository, rather than putting the burden of both
    ends squarely upon ourselves, but it seems like at any rate NPM won't be
    the answer to that.


    --Ken

    On 9/23/2012 8:36 PM, Tom Trenka wrote:
    My intentions here you mistake, young Skywalker, think I.

    NPM is a package manager that is aimed at a specific server-side
    platform (aka Node). To choose that as a way of distributing
    client-side, AMD, platform-neutral code would be, IMHO, a major mistake.

    I don't have a problem with us giving developers utilities that optimize
    and support the code that they are writing using a specific platform.
    All I'm counseling is that to try to integrate with something like NPM
    so directly would be a bad idea. At that point we'd consider just
    becoming part of Zend (no offense to Zend folks), or Tacos (look it up),
    or (insert server-side framework here).

    I'm also not advocating either way between Volo or CPM. Personally I
    like CPM (which I learned under Windows, right off the bat), and have
    not tried Volo--although having worked with James for many years, I
    would trust it because I trust the source of it. NPM though...the
    thought of using it to let people quickly and easily accomplish
    tasks--from the getgo, as in "I need a grid, dgrid looks nice, give it
    to me in a simple way without forcing me to go through basic .zip
    downloads and then go through a setup headache and a half--that gives me
    the shivers.

    -- Tom

    On Sun, Sep 23, 2012 at 6:04 PM, Kenneth G. Franqueiro
    <kgf at dojotoolkit.org wrote:

    Either way, we'll be relying on a platform, and I agree with Rawld RE
    Java not being any less toxic than Node, so I'm not sure why Node is
    being singled out here. Currently our build system requires Java if you
    want minification (Closure and ShrinkSafe both require it), and this is
    a dependency I'd love to see us have the option of shedding, and I
    thought we were looking forward to allowing that to happen with UglifyJS
    for 2.0.

    While I guess we could look to support both Node.js and Rhino for
    everything, I'm not sure whether it's worth the effort, and I'd rather
    not strike modern tools from consideration just because they don't
    support Rhino.

    If you're going to be worried about conclusions that people may or may
    not jump to about what we're "seeming to advocate", I'd be far more
    worried of the appearance of being stuck 10 years in the past behind
    other JS libraries because we're still leaning on Java/Rhino. At the
    risk of sounding like one of 'em darned little whippersnappers who don't
    know what it's like to walk uphill in the snow both ways, I'd say 2.0 is
    our chance to get with the times already.

    --Ken
    On 9/23/2012 5:11 PM, Tom Trenka wrote:
    Right. And, according to Kit's document Volo requires node and NPM.
    So, if your assertion of no dependency on node is a requirement,
    then Volo is disqualified. (CPM just needs a trivial install script
    for windows.)

    iiuc, CPM uses Java. So either way, these things can't be pure JS.

    I see and respect your point. I'm just not sure I agree that Java is
    any less toxic than Node...particularly since they (Node) appear to
    be supporting windows these days. But, this is likely a religious
    argument.


    I agree; all I'm pointing out is that tying our package system to a
    particular platform might seem like we are advocating development under
    that platform to the exclusion of others. While it does seem like Node
    is where most of our server-side tools are heading, I just don't want
    users of Dojo that don't develop under Node to feel "left out in
    the cold".
    -- Tom


    _______________________________________________
    dojo-contributors mailing list
    dojo-contributors at mail.dojotoolkit.org
    <mailto:dojo-contributors@mail.dojotoolkit.org>
    http://mail.dojotoolkit.org/mailman/listinfo/dojo-contributors
    _______________________________________________
    dojo-contributors mailing list
    dojo-contributors at mail.dojotoolkit.org
    <mailto:dojo-contributors@mail.dojotoolkit.org>
    http://mail.dojotoolkit.org/mailman/listinfo/dojo-contributors




    _______________________________________________
    dojo-contributors mailing list
    dojo-contributors at mail.dojotoolkit.org
    http://mail.dojotoolkit.org/mailman/listinfo/dojo-contributors
  • Rawld Gill at Sep 24, 2012 at 12:51 am
    To be crystal clear: my *only* reason for wanting to fully flesh out NPM one way or the other is marketing:


    * it is *the* package manager for Node
    * Node is very hot and will likely remain so
    * there is no clear alternative


    I understand that NPM is not viable for our use as it is today. But I still don't see/understand the precise things that need to be "fixed" to make it work for us...nor understand that cost.

    Tom Trenka

    NPM is a package manager that is aimed at a specific server-side platform (aka
    Node). To choose that as a way of distributing client-side, AMD, platform-
    neutral code would be, IMHO, a major mistake.

    I have a quibble with this analysis, which further points to my motivation for pressing this discussion. Node is not just a server-side platform. It is a native-hosted JavaScript environment. E.g., our build system is not a server program.


    The point is, Node is currently the native-hosted JavaScript environment of choice. I think that it is likely to be so in the long run...particularly if they lose their last bit of dogma and figure out that threads aren't always bad (recall, early talk about windows..."we'll never implement there because it's a defective platform").


    And some of Dojo is useful in Node, so we want to be there anyway.


    I see JavaScript everywhere, not just the browser. Node makes this possible. I'd like to leverage Node's--and, by extension, NPM's--market dominance to publish "Dojo Everywhere". But, if and only if it is technically rational and economically feasible.


    --Rawld
  • Kitson Kelly at Sep 24, 2012 at 1:24 am
    On 24 September 2012 05:51, Rawld Gill wrote:



    I see JavaScript everywhere, not just the browser. Node makes this
    possible. I'd like to leverage Node's--and, by extension, NPM's--market
    dominance to publish "Dojo Everywhere". But, if and only if it is
    technically rational and economically feasible.

    --Rawld

    "One Ring to rule them all, One Ring to find them, One Ring to bring them
    all into the darkness and bind them."


    Sorry couldn't resist, but I do agree with Rawld, I see JavaScript becoming
    more and more ubiquitous and it is likely NodeJS that will will continue to
    lead the charge in the non-browser based arena and I am a firm believer
    that Dojo has a role to play in that too.


    Anyways, I will flesh out the npm option in the document and highlight the
    advantages and disadvantages of that course of action. It is a fair point
    in that we do need to answer why or why not specifically with npm because
    it would be the "obvious" choice.
    -------------- next part --------------
    An HTML attachment was scrubbed...
    URL: http://mail.dojotoolkit.org/pipermail/dojo-contributors/attachments/20120924/f4af5ad4/attachment.htm
  • James Burke at Sep 24, 2012 at 6:27 pm

    On Sun, Sep 23, 2012 at 9:51 PM, Rawld Gill wrote:
    To be crystal clear: my *only* reason for wanting to fully flesh out NPM one way or the other is marketing:

    * it is *the* package manager for Node
    * Node is very hot and will likely remain so
    * there is no clear alternative

    I have some quick notes (probably not in-depth enough though) on why I
    did not choose npm here:
    https://github.com/volojs/volo/wiki/Prior-art


    The big things for me:


    * It is node first. Isaac has said he is fine if people put browser JS
    in npm, but they are not likely to make any special changes to npm
    just to fit browser JS needs.


    * Its installation assume node's multiple, nested node_modules IO
    rules, and that every package is a directory. I do not believe that
    fits well with browser JS, where it is common to just have single JS
    files in a 'baseUrl', and we need to have one IO lookup, hopefully
    based on conventions instead of config blocks.


    * The single namespace of npm makes it confusing to mix in browser
    code too. Search for jquery in npm as an example. That jquery is close
    to, but not exactly, what the jquery site publicizes. There is a
    'jquery', 'jQuery' and a 'node-jquery' in there too.


    Node has purposely not tried to consider other environments or JS
    platforms when constructing its design. Browser-based systems should
    do the same -- work out what is best for them, and then if it seems
    like there is enough overlap/reuse then talk with the node folks about
    it.


    However, these sorts of problems are not where the people that make
    node and npm have their minds at. They have moved up the stack and are
    focused mainly on the details for making great evented servers. For
    them, package management, code layout and a module system are solved
    problems for what they need.


    Some possible ways to reuse npm's code though:


    You could take just the npm registry code and set up a new location
    for for publishing browser JS. Then modify the npm source (in a fork)
    to install the downloaded tarballs into a browser JS-friendly way. Or
    just create your own browser tool that consumes the API/tarballs from
    the registry. I think this is generally the path jamjs has taken.


    The npm registry is couchdb-based, so it has some interesting
    replication features that may be useful for mirrors.


    As for libraries that support both browser and node: they should
    expect to publish in multiple places, a browser registry (maybe more
    than one, if they want to hedge bets on a winner) and for node use, in
    npm.


    James
  • Kitson Kelly at Jan 8, 2013 at 5:54 am
    All:


    Resurrecting an old thread to point out a rather useful article on the
    state of play of JavaScript package management:
    http://wibblycode.wordpress.com/2013/01/01/the-state-of-javascript-package-management/


    I am still of an opinion that there is a significant enough gap between
    what we need for npm and volo not to work "as-is" for us in Dojo 2.0.
    Also, npm will simply not bend to our needs and it would be irresponsible
    for us to bend volo to our needs, because its goals and objectives are
    significantly different from ours. I will take a look (eventually) at the
    other package managers mentioned and see if there is enough there for us to
    potentially adopt one of them versus a "build your own".


    Regards,
    Kit
    -------------- next part --------------
    An HTML attachment was scrubbed...
    URL: http://mail.dojotoolkit.org/pipermail/dojo-contributors/attachments/20130108/c45537bb/attachment.htm
  • James Burke at Jan 9, 2013 at 2:04 am

    On Tue, Jan 8, 2013 at 2:54 AM, Kitson Kelly wrote:
    All:

    Resurrecting an old thread to point out a rather useful article on the state
    of play of JavaScript package management:
    http://wibblycode.wordpress.com/2013/01/01/the-state-of-javascript-package-management/

    I am still of an opinion that there is a significant enough gap between what
    we need for npm and volo not to work "as-is" for us in Dojo 2.0. Also, npm
    will simply not bend to our needs and it would be irresponsible for us to
    bend volo to our needs, because its goals and objectives are significantly
    different from ours.

    I'm open to knowing what Dojo might need extra from volo. From the
    thread/doc it seems like you have concerns that is it focused on
    "deployment", but not sure I know what means for sure. Feel free to
    contact me off-list if this would be a rehash.


    Out of the other options, I believe you will find deficiencies with
    component, ender and bower, and they do not have any knowledge of AMD.
    Jam may be interesting since it knows about AMD. It is probably too
    requirejs-specific, but that may be workable, particularly if dojo and
    requirejs have the same config options implemented, at least the main
    ones, like baseUrl, paths, packages, shim.


    James
  • Kitson Kelly at Jan 13, 2013 at 3:31 am
    I had an off-ML discussion with James.


    In summary, some of the concerns I had were likely irrelevant
    or solvable in other ways I think would be acceptable. There were a couple
    of items that James indicated that he would be willing to consider for volo
    (and other projects seem to be interested in similar features).


    One thing that would appear to be unavoidable though is leveraging some of
    the extensibility of volo to better integrate it into the toolchain. This
    would mean either distributing a version of volo with that configuration or
    providing that configuration in a way that it is easy for a developer to
    use. It is unlikely we would be able to get to a situation where a
    "vanilla" volo would integrate into the Dojo toolchain seamlessly.


    So I think the choice for us boils down to two options:


    - Continue down a bespoke path, enhance cpm to meet the needs of Dojo
    2.0. Advantages are that we think the problem should be solved in the
    packaging tool, we can solve it there. Disadvantages are we have to expend
    effort in fully maintaining a package tool.
    - Adopt volo. Advantages is that we would be drawing on more than
    ourselves. Disadvantages we will still have some work to integrate it into
    our toolchain and we might end up at some impasse in the future that
    results in a fork.
  • Rawld Gill at Sep 23, 2012 at 1:01 pm
    I'm not advocating NPM. I am advocating a serious look owing to Node's and NPM's popularity (we can't continue to be the best technology with lagging uptake).


    In that spirit, consider these counterpoints:

    From: Kitson Kelly

    * The npm registry is wholly independent of GitHub and requires a
    registry in order to find packages,

    CPM has its own registry.


    The ability to read packages from GitHub is clearly a requirement. Other than that, who cares about GitHub.

    and is clearly geared towards serving NodeJS.

    I don't understand the implications of that assertion.


    Also, doesn't CPM stand for "CommonJS package manager" and yet AMD is rejecting the module structure of CommonJS?

    We would either have to integrate every package into the "NodeJS registry"

    We have to integrate every package into some registry. How is that different than CPM?

    (although they wouldn't be NodeJs modules)

    Some of our modules *should* be runnable on Node. Doesn't that make them "Node modules".

    or create a separate registry and get everyone to "re-point" at that.

    I think that would defeat the whole purpose of using NPM...so we shouldn't do this.

    * npm by default installs packages in ways that are geared towards
    server side frameworks and resolution of modules for NodeJS. For example in
    most cases "npm install module" would put it into "node_modules" of the root
    directory. That alone would be confusing to end developers.

    Perhaps an extension to NPM would have a storage tree at "amd_packages".


    [snip]
    * I am not impressed with the care, maintenance and governance that
    npm and the associated website is given. Issue #116
    <https://github.com/isaacs/npm-www/issues/119> shows a level of personal
    frustration I have, and I recently have been having significant issues with even
    getting on to npmjs.org recently.

    This is indeed disturbing.

    * Its governance isn't fully clear in my mind, and seemed to be slightly
    less "open" than we maybe accustomed to, although I am not really in a
    position to comment on this, it was only what I could glean. In particular I
    couldn't easily figure out how contributions are made (simply pull requests,
    maybe to the GitHub repo) and it seems that it is wholly managed by Isaac.
    Where as with the other two, we understand their governance models and in
    particular, I noticed that James has gone out of his way to make it clear. (As a
    side note, I think it is becoming increasingly important for us to remind people
    that just choosing an open source license doesn't make your software open)

    It's MIT licensed. Since it wouldn't be part of the toolkit, it can't pollute our IP. So, legally speaking, I don't see a problem.


    Process-wise, I think we'd all rather work with Kris and/or James. Writing an NPM extension, while technically possible, may be too painful...maybe Isaacs would resist rather than embrace.

    * NodeJS (and CommonJS) for whatever reason have "rejected" AMD. It
    is likely that there will be further divergence in the future. My estimation is
    that npm will, by its nature, do whatever NodeJS does. If there is further
    divergence between AMD and NodeJS modules, we will be left out in the cold.
    My estimation is this risk is less with volo, because it is obviously committed to
    support AMD.

    I'm still not clear how the content of modules affects the choice of package managers so deeply. As long as the package.json is well-defined, what's in the package should be mostly irrelevant.


    That said, while NodeJS is very popular, since it tends to concentrate on non-browser-hosted code, it represents a tiny fraction of all the JavaScript out there. To me, this is the best reason to rejection NPM, and instead try to build the winning AMD package manager.

    I honestly don't know if an extension would be viable or not, but if it were, we
    would have to say "what you need to do is install npm, then install our
    extension and then you can finally install Dojo". Of course we could derive a
    single installable, but I don't necessarily see how that would be different from a
    fork as likely any upstream changes in npm would have a negative effect on the
    extension.

    Hmmm, looking at your doc:


    * How is that different than Volo?
    * cpm doesn't work on win--a huge percent of the market--currently.




    I don't know how hard it would be either. But since the complete problem of a package manager is fairly simple, it's hard for me to imagine it would be that hard. But, then again, maybe Isaacs will make it painful and not worth the effort even if all the other issues could be addressed.

    But in the end, it is a discussion document. All I could add to it was my point of
    view. If we really feel that npm is a viable option, then I am all for discussing it.
    You are right that the penetration will significantly greater, but npm isn't a
    JavaScript package manager, it is a NodeJS Package Manager, and I think it will
    always be. If we feel my points above aren't valid (or not material to the
    decision) then I can further investigate what we would need to do in order to
    bend npm to our will. I just didn't think there was enough juice in the squeeze.

    Your document is awesome. It the very least, consequent to discussing and rejecting NPM, we'll be able to answer the FAQ, "Why not just use NPM?"


    --Rawld
  • Rawld Gill at Sep 23, 2012 at 4:51 pm

    -----Original Message-----
    Rawld Gill
    * cpm doesn't work on win--a huge percent of the market--currently.

    That's wrong. CPM advertises it works on windows.


    --Rawld
  • Ben hockey at Sep 23, 2012 at 3:43 pm

    On Sep 23, 2012, at 9:08, Kitson Kelly wrote:


    The npm registry is wholly independent of GitHub and requires a registry in order to find packages, and is clearly geared towards serving NodeJS. We would either have to integrate every package into the "NodeJS registry" (although they wouldn't be NodeJs modules) or create a separate registry and get everyone to "re-point" at that.

    npm can work with urls that point outside of its registry https://npmjs.org/doc/install.html.


    ben...
    -------------- next part --------------
    An HTML attachment was scrubbed...
    URL: http://mail.dojotoolkit.org/pipermail/dojo-contributors/attachments/20120923/c7398dce/attachment.htm

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupdojo-contributors @
categoriesdojo
postedSep 18, '12 at 3:57p
activeJan 13, '13 at 3:31a
posts22
users7
websitedojotoolkit.org

People

Translate

site design / logo © 2021 Grokbase