On Mon, Jul 23, 2012 at 6:53 AM, Maho <lukasz.m...@pagema.net> wrote: > > W dniu czwartek, 19 lipca 2012 06:40:19 UTC+2 użytkownik C Anthony Risinger > napisał: >> >> On Thu, Jul 12, 2012 at 4:19 AM, Łukasz Mach <lukasz.m...@pagema.net> >> wrote: >> > W dniu 12.07.2012 11:17, C Anthony Risinger pisze: >> > >> > Would it be very bad idea to add site-packages to -I ? (by hand or by >> > default)? >> >> that can cause some rather unexpected things to happen, like importing >> the wrong core stdlib modules. im pretty sure the --search-path stuff >> is farther down the chain, so it *might* work ok ... it's not as >> detrimental as installing pyjs libs to site-packages, > > > Heh, I'm curious why... why pyjs is done in different way than many other > packages. I mean it doesn't use setuptools/distutils, but has it's own > "third" way of being installed in system. > > It would be very handy to let me just do "pip install pyjamas" / "pip > install pyjs"
we aren't in disagreement -- i didn't write this implementation nor do i know why it's does what it do. in good time it will be corrected ... but that time is not today ... well, unless you make it so ;-) >> but i still >> wouldn't advise it. > > 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>` ... 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. > 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. -- C Anthony --
