On 10/10/2013 10:35 PM, Glyph wrote:
On Oct 9, 2013, at 6:43 PM, Steve Waterbury <water...@pangalactic.us> 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.
