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

--



Reply via email to