BTW, I think you&#39;re right (@James) on the idea that a package needs to be grabbed at dev time, and deployed as a part of a deployment; being able to download and unzip something in a stock directory setup and using even the current dojo.require would be fine, as long as it&#39;s not difficult to set up with any dependencies said package might have.  I really don&#39;t think we need a tool for this, and I&#39;m not entirely sure we need packages to be loadable by an application.  And though I have not played with Node or CommonJS, I find it hard to believe that you would need to load a package full-on at run-time in those environments as well.<div>
<br></div><div>Perhaps we&#39;re over-thinking this a bit?</div><div><br></div><div>-- Tom</div><div><br><div class="gmail_quote">On Wed, Aug 25, 2010 at 3:41 PM, James Burke <span dir="ltr">&lt;<a href="mailto:jburke@dojotoolkit.org">jburke@dojotoolkit.org</a>&gt;</span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">2010/8/25 Tom Trenka &lt;<a href="mailto:ttrenka@gmail.com">ttrenka@gmail.com</a>&gt;:<br>
<div class="im">&gt; What I *am* saying is that if there is to be packages, we *cannot* force<br>
&gt; people to download and use a tool just to get started with anything that is<br>
&gt; not &quot;in the box&quot; for Dojo 2.0.  If there&#39;s no alternate ways of setting up<br>
&gt; packages, such as easy manual setup, a web-based tool (i.e. zero-install),<br>
&gt; or any other methods (which I think is part of the point of this thread),<br>
&gt; then we lose.<br>
<br>
</div>A zero install option is easier if the package directory layout/path<br>
assumptions were easier to handle, and if legacy scripts did not have<br>
to be supported.<br>
<br>
I can see a config option for RequireJS that says something like<br>
&quot;onlyPackages&quot;: true, which indicates that only packages are in play,<br>
and if a specific package does not have a specific path mapping, then<br>
always look in a specific subfolder, call it &quot;packages&quot;, and it<br>
assumes all of those packages follow the packageName/lib/main.js<br>
mapping for the module that represents require(&quot;packageName&quot;).<br>
<br>
This means though that the packages have to become *very* uniform.<br>
<br>
Remote packages are harder to support manually. It is easy enough to<br>
support a package mapping to the package&#39;s lib directory, but in the<br>
package spec, the mappings for a package&#39;s dependencies are in the<br>
package.json file. So discovering the mappings for nested dependencies<br>
is harder. This was easy in Dojo 1.x land where dependencies were<br>
mostly on dojo/dijit/dojox modules that were all co-located.<br>
<br>
And as I indicated before, trying to use XHR to load a remote<br>
package.json file is fraught with errors. Letting the developer<br>
struggle through those errors does not help the image of a toolkit. A<br>
command line tool is more elegant and developer-friendly. There can be<br>
some initial issues with installing Node or Java, but the other errors<br>
it prevents make it worth it. IMO :)<br>
<br>
You can try to convince the CommonJS folks to support an xdomain,<br>
browser-friendly package.json, but that is yet another thing to<br>
include in a package. I would not want to pin my hopes on that. I want<br>
the system for package/dependency discovery to work the same on server<br>
side and a browser-targeted project. Not every CommonJS developer will<br>
want to do a browser-friendly version, and I still want to have access<br>
to those packages. The moment there is mixed mode packages (some with<br>
package.json, some that include package.js), then those are more<br>
special cases for the developer to wade through.<br>
<br>
It is probably worth trying to think of another way to deliver and<br>
consume packages. The tricky parts with the current package layouts:<br>
- The path to the modules (the &quot;lib&quot; mapping) inside a package can be<br>
configurable in package.json<br>
- Mappings for some of the module IDs used in the modules are stored<br>
in package.json<br>
<br>
That approach makes things more decentralized, more flexible, but it<br>
does cause some issues for the browser where we just want one path to<br>
load a module, and some of that path/dependency knowledge is in the<br>
package.json.<br>
<div class="im"><br>
James<br>
_______________________________________________<br>
dojo-contributors mailing list<br>
<a href="mailto:dojo-contributors@mail.dojotoolkit.org">dojo-contributors@mail.dojotoolkit.org</a><br>
</div><div><div></div><div class="h5"><a href="http://mail.dojotoolkit.org/mailman/listinfo/dojo-contributors" target="_blank">http://mail.dojotoolkit.org/mailman/listinfo/dojo-contributors</a><br>
</div></div></blockquote></div><br></div>