W dniu 23.07.2012 14:29, C Anthony Risinger pisze:
[...]
Also, I think that I'm thinking against "pyjamas philosophy" (well, you said
that there is no pyjs philosophy, but apparently you're wrong), but I think
that we should migrate to situation when I can "pip install
some_other_library" and that library is usable in pyjs app until it use
features not supported by pyjs (eg. native code).
there is no way to know it doesn't work -- it's either breaking things
in a glorious explosion or a subtle incompatibility or anywhere in
between. 90% of the stdlib is overwritten by pyjs custom versions
anyway, and many many packages try to import C-extensions and the like
as part of their startup routine.
there are libraries that do in fact work fine, but there are many
constraints and it's not worth the problems and wasted time just so
people don't have to `cp <a> <b>` ...
Well, when you have many virtualenvs, then it's not just copy <a> <b>,
but things became more complicated.
really, it's easy enough to try them one at a time as needed via
copying or symlink, and i see absolutely no gain in opening that can
of works right now.
as for `pip install pyjs` -- yes! -- of course.
If we're ok with future pip install pyjs, then we should be consistent
and be ok with pip install library-used-in-pyjs
Why I'm talking about it? Because I think it's worth of having kind of
"ecosystem" around pyjs. Like, not every new functionality I invent is
added to pyjamas itself (which will end as monstrous superlibrary), but
to separate, small python package.
Like django addons, I need django-celery, I do pip install django-celery
and voila :). I don't need to have diango-celery, celery, rabbitmq,
friends and relates in django ...
I think there are following ways to play with it:
1. leave as is, cp <a> <b> is enough and I'm alone with my needs :D
2. use dist-packages/site-packages ... but *only* packages/modules which
are *explicite* marked as usable in pyjs. How should they be marked?
Maybe property of module/package, or maybe some global "checklist" -
it's matter of discussion.
3. or, use own, pip-like (or hacked pip) tool, own repository of pyjs
stuff.
Also, is it desired that when I do "import some_external_library", and this
library is not reachable by pyjs app, then I don't get compile-time error,
not even warning?
this has come up a few times in the past, but no it's not an error --
your C compiler does not throw an error (`cc` not `gcc`) either --
it's just a 1-to-1 translation. the translator itself is not even
aware of what "import" means ... the linker handles all of that. i
have some initial branches locally that rework the linker near 100% to
clean OOP, but they are not ready.
tl;dr, maybe it should throw something, but i'm not sure a warning is
appropriate... maybe an INFO. --dynamic-load exists specifically to
allow for "missing" libs at translation time ... it's very dependent
on context and intent.
Ok, I get the point. However, note that errors thrown by pyjs in browser
are usually misleading, not obvious. And I think, that , when no
"--dynamic-load" used (which I don't know how works yet), then if
compiler /knows/ what file should it translate from .py to .js and it
/does it/ , then it should /do something/ when it can't find the module.
At least - it's obvious behaviour for me :).
In gcc metaphore - when I do "#import "library-not-in-path.h" then it
will throw an error.
In import => "function use" gcc metaphore , then cc won't throw an
error. But pyjsbuild is kind of gcc -o, isn't it? And gcc -o will raise
me error when it can't find -llibrary in path, or it cannot find used
name within used -llibraries.
--
pozdrawiam
Łukasz Mach - lukasz.m...@pagema.net
--