Re: Qooxdoo Framework and a pythonic way of installation
thron7 <thomas.herchenroeder <at> 1und1.de>
2012-02-01 10:52:17 GMT
Stefan,
On 02/01/2012 09:29 AM, Stephan Adig wrote:
thanks a lot for your afford. Just pass me the location of the
package and I'll have a look into it.
Mh, I cannot find it. I tried the package search on debian.org but
failed. The search only allows you to search backwards until Lenny,
and I have no idea if qooxdoo is supposed to be in Lenny or if it
was only in prior releases, or if in Lenny from what repo.
Here is a link to the initial (I believe) bug to bring qooxdoo into
the distribution:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=485975
The guy working on it was Niko Tyni. One of the motivations to bring
in the package was Tobi Oetiker's "smokeping" app, which relies on
qooxdoo, so they would need it to re-build smokeping from source.
If you look at the bug it's from 2008, but I know that Tobi and Niko
were working on it also at later times (e.g. Tobi made a mailing
list posting in that regard on 06/2009).
<at> Tobi, can you chime in to give a more current account?!
Why I'm asking is, that actually it's not like the dojo or jquery
packages in Debian/Ubuntu.
Dojo e.g. does come normally with some binary helper packages to
provide the minimizing of the javascript library. So, the goal of
the package was to remove this dependency and use system libs
coming from Distribution packages.
I see, but still qooxdoo would be a lib too, right?!
What I would like to do is to remove eventual existing code
duplication (e.g. python libs which are already available as
packages and which are used by the qooxdoo python generation
module) and get everything to work.
I'm not sure this would be worth the effort, or would even work. For
one thing, the extra Python modules we are including are tiny, so
there wouldn't be much space wasted in having them even if there
were system-provided versions for them.
Then we e.g. use "ElementTree", which is in Python 2.5 as standard
module xml.etree.ElementTree, but the version we are using is newer
than the one in the standard lib, and is received from the author's
repository directly. Using the standard modul instead would in fact
break the generator code.
You could probably replace the "pyparsing" module we ship, but you
would then need to adapt the generator code individually, as we have
renamed the package to "pyparse", exactly for the reason that it
doesn't clash with a potentially globally installed pyparsing.
Then there is "polib", but our module contains patches that we have
applied. Replacing it with a standard polib would again most likely
break the generator.
And even if there were a globally installed module of the same name
(this could be the case e.g. with the "graph" module), within the
generator we're installing our own library path "tool/pylib" *in
front* of the Python search path for modules, so our own modules are
always found first.
So why would you go through all these efforts to replace third-party
modules in the SDK with their distribution counterparts, provided
there is any, when you have so many caveats and pitfalls?! For what
benefit? Also, people seemed to struggle with the Debian package for
qooxdoo [1], so the old efforts might not be successful in all
cases.
If this gives rise to more conflicts I'd be interested to hear about
them.
Keep us updated,
T.
[1]
http://stackoverflow.com/questions/3808265/qooxdoo-and-debian-lenny
------------------------------------------------------------------------------
Keep Your Developer Skills Current with LearnDevNow!
The most comprehensive online learning library for Microsoft developers
is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
Metro Style Apps, more. Free future releases when you subscribe now!
http://p.sf.net/sfu/learndevnow-d2d
_______________________________________________
qooxdoo-devel mailing list
qooxdoo-devel <at> lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel