On Tue, Oct 18, 2011 at 1:32 PM, Joe Knapka <[email protected]> wrote:
> Thank you for your reply; your advice worked perfectly! I do have
> a couple of follow up questions/comments:
>
I'm glad it could help. Once you know all of it, it's easy. It's the
learning curve. I went through the same thing.
> 1) After running "setup.py develop", "paster setup-app" died with an
> unresolved import of genshi.filters. "easy_install genshi" fixed that, and
> the app is now running without any trouble. But I'm wondering if genshi
> was supposed to be installed by setup.py.
>
It definitely should have. It sounds like, for some reason, genshi was not
listed in your setup.py. You can simply add it to the install_requires list
in setup.py, and that will fix the problem.
> 2) In general, is it safe to assume that all the *source* files created by
> "paster quickstart" are safe to keep in version control, and will work
> in somewhat different TG environments (eg within the TG2.x series of
> releases)? (I think my original misstep was to actually configure and
> run my quickstarted app before committing the primal source code
> to VC, which meant my egg-info directory and maybe some other
> inappropriate stuff got checked in.)
>
If you're going with a fresh quickstart, and have not run "python setup.py
develop" or "paster setup-app development.ini" yet, then it's almost safe to
include everything. During the quickstart generation, a couple of the .py
files are loaded, and this results in some .pyc files being created. While
those files should be pretty safely portable most of the time, they can
produce problems. Always add those to your ignore list before the initial
import, or remove them right away afterwards. Either one, just to play it
safe and remove future problems.
> 3) I had originally created my project within the directory tree created
> by virtualenv. You seem to imply it's not necessary, and may even be
> wrong, to do that. Am I understanding you correctly?
>
You're understanding very correctly. Basically, you're working with two
separate items: virtualenv creates a copy of Python (effectively, not in
reality, except maybe on Windows), giving you a place to experiment that
won't corrupt your system's copy and affect other programs (or have them
affect what you're making). The second thing is your project. You can store
everything together, but, personally, I do not. I have a directory named
${HOME}/venvs which contains all my virtualenv, and then I work on my
projects under ${HOME}/src . This keeps things separate, and lets me keep
the pieces more easily separate in my mind. It's not required, but it is how
I work and helps me.
--
Michael J. Pedersen
My IM IDs: Jabber/[email protected], AIM/pedermj022171
Yahoo/pedermj2002, MSN/[email protected]
My Online Resume: http://www.icelus.org/
Twitter: pedersentg
--
You received this message because you are subscribed to the Google Groups
"TurboGears" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/turbogears?hl=en.
