[Grok-dev] Re: Ignas's work on grokproject
Ignas Mikalajunas
ignas.mikalajunas at gmail.com
Wed Sep 12 18:28:20 EDT 2007
Hi,
> I shall note that he's then going to be irritated by pretty much every
> other Python web framework (Django, TG, Pylons, ...) because they all
> use easy_install. Or maybe he wouldn't be because they might be
> mentioning workingenv or vpython in their docs as means to avoid root
> access.
Yes, my obsession with not installing things into /usr/lib is making
it a bit difficult for me to accept the current situation. And even if
it works for Django or Pylons, the fact that grok uses buildout by
default using system python is something I think should be avoided...
Jim Fulton iirc is not very keen on supporting system python when it
comes to buildout. Thus if buildout or buildout based project breaks
because of packages installed in your system (and it breaks,
especially if it is as big as schooltool) the first thing that is
recomended is "do not use system python".
Of course you can compile a new python (most Zope corp developers do that).
Use workingenv though wrkingenv will not work with some packages
installed using zc.recipe.cmmi recipes. You surely can't install
libxml2 using buildout in workingenv.
Or setup a virtual python. Virtual python was the most reliable way of
really easily installing buildout based projects without a root
account into a local directory, so i even included it into
"bootstrap.py" to reduce the ammount of moving parts. It seems that it
works quite well for schooltool, but for grokproject - i had to add
"ez_setup.py" to the "sandbox-maker" because of some technical issues
(easily fixable with access to PasteSript source code).
I am sorry for wasting the time of your project, just that I like you
the most. And think that having the amazingly easy to use and install
(Ubuntu), and the language that is so easy even kids can learn it
(Python) requiring users to use sudo, download and install things
unrelated to your project and set them up just to try out Grok is
making me feel very sad. And I would like it to be as close to pushing
1 button as possible, no matter how clueless you are, and whose PC is
it ;)
> I'm inclined to say that this is first and foremost a documentation
> problem. I chatted with Ignas about this last night on IRC [1] and
> already gave him the advice to add a footnote or section to the tutorial.
I guess yes. I mean schooltool usecases and users are quite different
from the ones encountered by your project. Just that I was so glad
when I found a way to work around buildout limmitation of not
supporting system python (without compiling a new python, and without
having a root, and without requiring users to perform more than 1
shell command) that I wanted to share it with the rest of the python
comunity ;) perhaps too enthusiastically.
> If Ignas would like to, I'm inviting him to check his modifications into
> a grokproject branch. This would make it much easier for me to review.
Not sure my code belongs there, as I am not modifying grok in any way.
The script just creates a "local" virtual python, bootstraps buildout
using that clean python, installs setuptools into the local python
(this can be avoided in the future), and buildouts grokproject. You
can even delete the directory you have just extracted and your system
is as clean as it was before, I mean - is there a better way to try
out Grok? Is there a reason not to? :)
Ignas Mikalajūnas
More information about the Grok-dev
mailing list