The following 2 files had syntax errors and looks like some sort of a cross between pythong and C++ code. Since pip install does try to compile them all to .pyc files.
library/pyjamas/selection/HtmlBBox.py ibrary/pyjamas/media/NetworkState.py.needsfixing So have temporarily renamed them as folllows library/pyjamas/selection/HtmlBBox.py ibrary/pyjamas/media/NetworkState.py.needsfixing Is that ok? Sarvi On Thursday, October 10, 2013 8:13:33 PM UTC-7, waterbug wrote: > > On 10/10/2013 10:35 PM, Glyph wrote: > > > > On Oct 9, 2013, at 6:43 PM, Steve Waterbury > > <wate...@pangalactic.us<javascript:>> > wrote: > > > >> On 10/09/2013 07:49 PM, Glyph wrote: > > A build.sh script means a tool that only works on UNIX. This > > is an antipattern, in my opinion. pyjsbuild ought to read a > > configuration file from the current directory if this is so > > common that everyone has to do it. (And yes, for every toy > > pyjs project I built, I had to do it too!) > > Agreed. I don't care how the configuration is done -- a config > file would be fine, and then it would make sense to have pyjsbuild > in your path ... and as in your later comment, the "build" process > could even be automated so you wouldn't even need pyjsbuild in your > path ... ;) > > >> NOTE: as you can infer from the path names in my build.sh, I am > >> using pyjs in a directory that is located inside a virtualenv, but > >> the virtualenv is for the backend [Django] of the app, not for pyjs -- > >> i.e., the pyjs libraries are not "installed" in the virtualenv. > > > > Why not, though? > > Because it's not necessary and doesn't buy anything. Actually > it wouldn't hurt anything, they would just be ignored. But > currently there is no reason to install them in the virtualenv. > > >> I keep my own library of widgets derived from pyjs widgets in a > >> separate repository, but I manage my app-specific pyjs code in the > >> same repository with the Django backend code for the app, in a > >> directory called "customjammies", which is purposely not a python > >> package so it's invisible to the Django app -- pyjsbuild includes > >> it in the "build" because of the '-I' flag. > > > > I understand that for the most part this code is not going to > > be invoked by the same interpreter, but it seems like it would > > be better for pyjs to just respect existing python conventions > > than to invent a parallel toolchain. Just look at $PYTHONPATH > > to locate dependencies, rather than having -I flags to various > > tools, for example. It's just less stuff to teach people. > > Right now it's quite hard to write a library designed for use > > with PyJS, because you have to explain where to put everything > > manually, rather than just saying 'pip install <mylib>'. > > That would be a good idea *if* pyjs were going to translate > code that can actually run as python code -- e.g., my idea > of having pyjs translate qt/wx applications. Otherwise, it > would make more sense for pyjs to have its *own* virtualenv ... > I agree that *that* would be a good idea. > > > This goes hand-in-hand with PyJS supporting more of the Python > > language, of course. If regular libraries could reasonably be > > made portable to the browser environment, then this would > > become _hugely_ powerful :). > > Agreed. > > > PyJS is one monolithic piece right now. It can get away with a > > crummy dependency-management strategy because it doesn't have > > any dependencies beyond Python: you just 'git clone' PyJS and > > run the tools. (Well, except you still need to run the > > 'bootstrap' script, so there is *already* some manual setup > > which pip could automate away for you.) ... > > True enough. > > > If it wanted to use > > Twisted to have a built-in demo server, for example, it would > > be 'git clone' plus 'pip install'; rather than 'pip install > > pyjs' and it fetches everything it needs. > > Now *that* is a selling point. Some of the old pyjs demos > had a php app on the back-end ... yuck! :p > > > But, more importantly, if PyJS were broken into five separate > > components (as people have been discussing with respect to the > > Great Schism), then it would be "git clone *five* repositories" > > and then set up your PYTHONPATH and who knows what else. I > > believe that this manual setup would be very offputting to new > > users. ... > > Agreed. > > > This is exactly why tools like pip and virtualenv > > exist; to automate all these boring code-aggregation tasks. > > Actually that's only *one* of the reasons pip and virtualenv > exist ... and IMO not the most important: allowing multiple > versions of python and/or libraries/apps to coexist peacefully on > one machine (and in the unix case, avoidance of the pesky "system > python" -- to be sure, the latter is a stupid problem that the > Linux distros should have solved themselves). > > >>> I'd have no expectation that after 'pip install' it would be > >>> usable as a regular platform Python library though. > >> > >> No, that would make absolutely no sense at all. > > > > I don't think it would make *no* sense. Since it's not > > designed for use as a library, it's not a high priority, but it > > would still be beneficial if it could work. For example, > > perhaps someone could write a higher-level framework that > > depended on PyJS to do JavaScript translation on the fly by > > monitoring filesystem events, to make the development cycle > > more Python-ish and less like building a big C++ app ;-). > > Interesting idea. *Then* it might make sense, though you had not > proposed that. In fairness, using pyjs as it is currently isn't > *that* much like building a C++ app, or you wouldn't catch me > doing it! ;) > > > -glyph > > Peace, > Steve > -- --- You received this message because you are subscribed to the Google Groups "Pyjs.org Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to pyjs-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
