I've made some progress on our package system, and I wanted to update
you on it so we can start trying it out. The main link to see the
available packages is here:
http://packages.dojofoundation.org/list.html

From bogus@does.not.exist.com Sat Jan 1 20:25:13 2011
From: bogus@does.not.exist.com ()
Date: Sun, 02 Jan 2011 01:25:13 -0000
Subject: No subject
Message-ID: <mailman.0.1294155673.3308.dojo-contributors@mail.dojotoolkit.org>

To install packages, you can download the CPM package manager from:
http://github.com/kriszyp/cpm

Or you can manually download them from the page above (along with
dependencies) and add them to the package configuration for your module
loader (RequireJS or Backdraft). Or
and follow the directions to install it.

Once you have installed CPM, here is real quick example to get you started:

* Create a project directory to try this out:

* Put the attached test.html in this directory.

* Create a js directory and install some packages:
mkdir js
cd js
cpm install requirejs master
(Note that we are installing the version "master" of RequireJS, once
0.22.0 is available we won't need to do that. Also ignore the error
about reading package.json, it doesn't have one).
cpm install commonjs-package-template
(see how this installs the package and dependencies, in this case, dojo)

* Load up test.html in the browser, hopefully it works for you (should
say "Hello World" if it works).

Also, http://packages.dojofoundation.org/list.html is intentionally ugly
to make sure it is clear that it needs to replaced with a nice user
interface for our packages.

Let me know if you have questions about any of that.

Thanks,
Kris





--------------080302060308060008090304
Content-Type: text/html;
name="test.html"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
filename="test.html"

PCFkb2N0eXBlIGh0bWw+DQo8aGVhZD4NCg0KICA8c2NyaXB0IHNyYz0ianMvcGFja2FnZXMv
cmVxdWlyZWpzL3JlcXVpcmUuanMiPjwvc2NyaXB0Pg0KICA8c2NyaXB0Pg0KICAgIHJlcXVp
cmUoe2Jhc2VVcmw6ImpzIiwgcGF0aHM6eyJyZXF1aXJlIjogInBhY2thZ2VzL3JlcXVpcmVq
cy9yZXF1aXJlIn19KTsNCiAgICByZXF1aXJlKFsicGFja2FnZXMiXSxmdW5jdGlvbigpew0K
ICAgICAgcmVxdWlyZShbImNvbW1vbmpzLXBhY2thZ2UtdGVtcGxhdGUvZGVtbyJdKTsNCiAg
ICB9KTsNCg0KICA8L3NjcmlwdD4NCg0KPC9oZWFkPg0KDQo8Ym9keT4NCg0KPC9ib2R5Pg0K
PC9odG1sPg==
--------------080302060308060008090304--

Search Discussions

  • James Burke at Jan 11, 2011 at 12:33 am

    2011/1/4 Kris Zyp <kzyp at dojotoolkit.org>:
    To install packages, you can download the CPM package manager from:
    http://github.com/kriszyp/cpm
    This is awesome, thanks Kris for putting the work into this! This is
    the kind of approach I was hoping for in a package manager. Some
    questions and comments:

    1) I installed the "has" package, and it's "main" config mentions
    "main":"./has.js", but I thought the "main" value was a module name,
    and not a .js file. I was looking at this page before and its "main"
    example:
    http://wiki.commonjs.org/wiki/Packages/1.1

    What has been your practical experience with "main" values? RequireJS
    assumes it is a module name at the moment.

    2) For normal RequireJS projects, I am going for a design where the
    user only specifies one script tag for the page, that looks like:
    <script type="text/javascript" data-main="path/to/main.js"
    src="path/to/require.js"></script>

    where main.js is the top level script for the page, and it has its
    require([]) call to start up the app. When I had thought about package
    config before I was thinking I would just inject it at the top of the
    main.js file, instead of having a nested require() call to load
    packages then load the page. I liked that it reduced the first
    blocking request on packages.js before doing the main app loading, but
    it does have the downside of some config blob at the top of the user's
    main JS file.

    However it works out I was hoping for something that would not have
    the nested require() boilerplate. Not sure how best to do this though,
    still feeling it out. Which leads to the next item...

    3) I keep wondering if CommonJS packages are really a good idea. I
    don't like the variability that the config for lib and main provide.
    It seems to lean towards configuration over convention. I would be
    open to entertaining a world where a package is just a directory and
    to get the main module, you always ask explicitly for it, so
    require("packageName/main") vs require("packageName").

    It would mean that a package manager may need to massage existing
    CommonJS-based packages though. I'm also not sure how much people want
    to avoid typing "/main" for each top level package entry point, or if
    package authors are OK with their scripts being at the top level of
    the package. But I am really not a fan of all the config junk, and its
    cost in a loader. I know you brought up a similar concern before about
    loader cost for it, just wondering if you thought more about it.

    4) You had talked about leveraging work done by npm: did you mean just
    using the same protocol, or more? Would it be possible to use the
    registry used by npm with cpm? How do you see those two things working
    together?

    5) It seems like it would be helpful if RequireJS created a
    package.json, I'll look into doing that.

    6) Along the lines of a RequireJS package: ideally I would want to
    deliver a much smaller package for use by end users. There is lots of
    stuff in tests, docs and build that are really not useful for people
    who just want to use require.js and its plugins. Any thought on how to
    do that via GitHub or some alternate cpm/cpr config? I normally just
    tag the master for a release. Maybe I would need to create some
    branches that had reduced file contents for each release?

    Thanks again, this looks really neat!

    James
  • Kris Zyp at Jan 12, 2011 at 11:09 am

    On 1/10/2011 10:33 PM, James Burke wrote:
    2011/1/4 Kris Zyp<kzyp at dojotoolkit.org>:
    To install packages, you can download the CPM package manager from:
    http://github.com/kriszyp/cpm
    This is awesome, thanks Kris for putting the work into this! This is
    the kind of approach I was hoping for in a package manager. Some
    questions and comments:

    1) I installed the "has" package, and it's "main" config mentions
    "main":"./has.js", but I thought the "main" value was a module name,
    and not a .js file. I was looking at this page before and its "main"
    example:
    http://wiki.commonjs.org/wiki/Packages/1.1

    What has been your practical experience with "main" values? RequireJS
    assumes it is a module name at the moment.
    It seems like in NPM packages that filenames were being used for main
    values. In the Dojo package.json, I followed the RequireJS pattern and
    specified a module name. I don't care which it is.
    2) For normal RequireJS projects, I am going for a design where the
    user only specifies one script tag for the page, that looks like:
    <script type="text/javascript" data-main="path/to/main.js"
    src="path/to/require.js"></script>

    where main.js is the top level script for the page, and it has its
    require([]) call to start up the app. When I had thought about package
    config before I was thinking I would just inject it at the top of the
    main.js file, instead of having a nested require() call to load
    packages then load the page. I liked that it reduced the first
    blocking request on packages.js before doing the main app loading, but
    it does have the downside of some config blob at the top of the user's
    main JS file.

    However it works out I was hoping for something that would not have
    the nested require() boilerplate. Not sure how best to do this though,
    still feeling it out. Which leads to the next item...

    3) I keep wondering if CommonJS packages are really a good idea. I
    don't like the variability that the config for lib and main provide.
    It seems to lean towards configuration over convention. I would be
    open to entertaining a world where a package is just a directory and
    to get the main module, you always ask explicitly for it, so
    require("packageName/main") vs require("packageName").

    It would mean that a package manager may need to massage existing
    CommonJS-based packages though. I'm also not sure how much people want
    to avoid typing "/main" for each top level package entry point, or if
    package authors are OK with their scripts being at the top level of
    the package. But I am really not a fan of all the config junk, and its
    cost in a loader. I know you brought up a similar concern before about
    loader cost for it, just wondering if you thought more about it.
    Originally CPM was doing much more massaging, essentially taking every
    package, and reworking into a conglomerate package. I have gone back and
    forth on this as well, there are enough pros and cons on each side, I
    have gotten pretty ambivalent, and was planning on just following
    whatever you did.
    4) You had talked about leveraging work done by npm: did you mean just
    using the same protocol, or more? Would it be possible to use the
    registry used by npm with cpm? How do you see those two things working
    together?
    Yes, NPM supports cross-registry entries. To test this I have put in
    entries in the NPM registry for compose, patr, and promised-io, which
    all redirect to packages.dojofoundation.org. You should now be able:

    npm install compose

    And should (hopefully, there have been some errors that we have been
    working through) install the package from our repository.

    I have not tried using CPM with the NPM registry yet.
    5) It seems like it would be helpful if RequireJS created a
    package.json, I'll look into doing that.
    The toolset should be tolerant of packages without a package.json. Of
    course you are welcome to create one if you want.
    6) Along the lines of a RequireJS package: ideally I would want to
    deliver a much smaller package for use by end users. There is lots of
    stuff in tests, docs and build that are really not useful for people
    who just want to use require.js and its plugins. Any thought on how to
    do that via GitHub or some alternate cpm/cpr config? I normally just
    tag the master for a release. Maybe I would need to create some
    branches that had reduced file contents for each release?
    I had assumed that your build will be potentially stripping down
    require.js at build time. I was planning on eventually adding support
    for registering direct archive URLs which would give you the ability to
    control a post-built version.
    Thanks again, this looks really neat!

    James
    _______________________________________________
    dojo-contributors mailing list
    dojo-contributors at mail.dojotoolkit.org
    http://mail.dojotoolkit.org/mailman/listinfo/dojo-contributors
  • Kris Zyp at Jan 12, 2011 at 9:27 pm
    Also, if you or anyone else want to take over the package
    management/installer project, that is fine with me, even if it want it
    as a sub-component of RequireJS. I have done about all that I want with
    it, and if module loader package configuration is going to continue to
    evolve, it might easier for module loader dev(s) to keep it in sync with
    module loader configuration API. I know that you had some great ideas
    with using the command line tool for scaffolding as well. (And I'd be
    glad to keep maintaining the package registry, unless someone wants that
    too).
    Kris
    On 1/10/2011 10:33 PM, James Burke wrote:
    2011/1/4 Kris Zyp<kzyp at dojotoolkit.org>:
    To install packages, you can download the CPM package manager from:
    http://github.com/kriszyp/cpm
    This is awesome, thanks Kris for putting the work into this! This is
    the kind of approach I was hoping for in a package manager. Some
    questions and comments:

    1) I installed the "has" package, and it's "main" config mentions
    "main":"./has.js", but I thought the "main" value was a module name,
    and not a .js file. I was looking at this page before and its "main"
    example:
    http://wiki.commonjs.org/wiki/Packages/1.1

    What has been your practical experience with "main" values? RequireJS
    assumes it is a module name at the moment.

    2) For normal RequireJS projects, I am going for a design where the
    user only specifies one script tag for the page, that looks like:
    <script type="text/javascript" data-main="path/to/main.js"
    src="path/to/require.js"></script>

    where main.js is the top level script for the page, and it has its
    require([]) call to start up the app. When I had thought about package
    config before I was thinking I would just inject it at the top of the
    main.js file, instead of having a nested require() call to load
    packages then load the page. I liked that it reduced the first
    blocking request on packages.js before doing the main app loading, but
    it does have the downside of some config blob at the top of the user's
    main JS file.

    However it works out I was hoping for something that would not have
    the nested require() boilerplate. Not sure how best to do this though,
    still feeling it out. Which leads to the next item...

    3) I keep wondering if CommonJS packages are really a good idea. I
    don't like the variability that the config for lib and main provide.
    It seems to lean towards configuration over convention. I would be
    open to entertaining a world where a package is just a directory and
    to get the main module, you always ask explicitly for it, so
    require("packageName/main") vs require("packageName").

    It would mean that a package manager may need to massage existing
    CommonJS-based packages though. I'm also not sure how much people want
    to avoid typing "/main" for each top level package entry point, or if
    package authors are OK with their scripts being at the top level of
    the package. But I am really not a fan of all the config junk, and its
    cost in a loader. I know you brought up a similar concern before about
    loader cost for it, just wondering if you thought more about it.

    4) You had talked about leveraging work done by npm: did you mean just
    using the same protocol, or more? Would it be possible to use the
    registry used by npm with cpm? How do you see those two things working
    together?

    5) It seems like it would be helpful if RequireJS created a
    package.json, I'll look into doing that.

    6) Along the lines of a RequireJS package: ideally I would want to
    deliver a much smaller package for use by end users. There is lots of
    stuff in tests, docs and build that are really not useful for people
    who just want to use require.js and its plugins. Any thought on how to
    do that via GitHub or some alternate cpm/cpr config? I normally just
    tag the master for a release. Maybe I would need to create some
    branches that had reduced file contents for each release?

    Thanks again, this looks really neat!

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

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupdojo-contributors @
categoriesdojo
postedJan 4, '11 at 10:38a
activeJan 12, '11 at 9:27p
posts4
users2
websitedojotoolkit.org

2 users in discussion

Kris Zyp: 3 posts James Burke: 1 post

People

Translate

site design / logo © 2021 Grokbase