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 > > <[email protected]<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 [email protected]. For more options, visit https://groups.google.com/groups/opt_out.
