On Oct 9, 2013, at 6:43 PM, Steve Waterbury <water...@pangalactic.us> wrote:
> On 10/09/2013 07:49 PM, Glyph wrote: >> >> On Oct 9, 2013, at 12:16 PM, Steve Waterbury <water...@pangalactic.us >> <mailto:water...@pangalactic.us>> wrote: >> >>> ... in particular, why it doesn't make sense to 'pip install' pyjs. >> >> Personally I'd love to be able to 'pip install' it simply so that I can >> do 'pip install pyjs' and then get pyjampiler and pyjsbuild on my $PATH >> automatically, since pip provides nice tools and automation for that. >> Plus that would make it easier for build systems that already support >> setuptools (debian, fedora, et. al.) to build ready-made PyJS packages. > > I think it would be easy enough to create a pip install that does > what you suggest. I suppose for some uses having that stuff on your > path might be good; however, some configuration is always needed to > use it for development, so just having that stuff in your $PATH is not > a big win, IMO. For example, for each app that you are creating you > will need to decide what parameters and paths to use when you run > pyjsbuild, which you will do every time you make a change to > your app code. The suggested way to do that is a build.sh script -- > I've attached one of mine so you can see an example. Since build.sh > is simply a shell wrapper for pyjsbuild, there's really no need > to have pyjsbuild on your path. 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!) > 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? > 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>'. 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 :). >> This would also make it a lot easier for PyJS to depend on other Python >> projects for its own use, so that they could be automatically installed. >> If PyJS is to be split up into multiple pieces, it should be able to >> use *itself* as a Python library :-). > > It already does that ... or else I don't understand what you're saying. 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.) 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. 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. This is exactly why tools like pip and virtualenv exist; to automate all these boring code-aggregation tasks. >> 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 ;-). -glyph -- --- 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.
