launchpad-dev team mailing list archive
-
launchpad-dev team
-
Mailing list archive
-
Message #06479
Re: Third party JavaScript parts + skinning
On Feb 13, 2011, at 2:48 PM, Robert Collins wrote:
> On Mon, Feb 14, 2011 at 8:00 AM, Paul Hummer <paul.hummer@xxxxxxxxxxxxx> wrote:
>> I would also agree. In fact, we already have some gallery code in lazr-js.
>>
>> However, in the next month or so, I have time scheduled to take all the
>> eggifying parts of lazr-js out, and make it strictly a javascript
>> library (all other parts will become their own projects).
>
> This sounds horrifyingly disruptive; please consider moving the
> javascript elsewhere, rather than moving the python widgets etc
> elsewhere. We're patching this library every few days at the moment,
> and the last thing we need is the sort of multi-day rework that occurs
> with this sort of change.
I was hoping someone else with more knowledge than myself would step in to say this, but I'll jump in.
This situation is precisely why I currently advocate what Brad described.
Here's a summary of my understanding. Please correct.
- We all like working with packaged software.
- YUI has a story for this. It is a story that the JS experts at Canonical have rejected: using Yahoo's CDN.
- lazr-js was supposed to be Canonical's story for this. It has at least two problems.
* First, it uses Python build tools for something that is JS only. We're already off on our own since we are not using the CDN, and this makes it more isolated. [I vaguely think there are other problems with this too?]
* Second, it is a shared resource, shared across Canonical. This encourages slower, more thoughtful changes that look towards building company-wide consensus. It is less appropriate for quick, application-specific work.
- Because of this, the Canonical JS experts are excited and pleased for Paul to do the work he describes.
Therefore, as I assemble the picture around me, we have a broken JS packaging story now that is both significantly in flux and not necessarily appropriate for including all of the sorts of things we need in our local applications.
My team's mission right now is not to solve Launchpad's or Canonical's JS packaging story, and I would not like to be slowed down by it. Brad's approach sounds reasonable, acknowledging that it is a stop-gap, and that we would like to use something better, and possibly even that Launchpad would want to help in Canonical's effort to figure it out better--as a separately scheduled effort.
I'm very happy to be corrected, but most happy to have a clear path forward on this that lets my team move quickly. Brad's is the only one I have (understand?) at the moment.
Thank you
Gary
Follow ups
References