> I use a similar structure, perhaps giving the virtualenv the same
> name as the Python package I'm working on in that venv. Really, the
> name doesn't matter except that it's descriptive (if you have
> multiple unrelated envs named trunk for example, that could be
> confusing). On my dev machine, I'll usually just have one venv per
> project (for trunk). On a server, I might have multiple tagged venvs
> for a project, like ~/Projects/MyProject-rel-0.1.
I tend to use more descriptive names than the package it contains, and
the structure I have within the virtual environment closely mirrors a
standard UNIX tree:
(Where ~ = the virtual environment home.)
~/{bin,lib} — Standard virtualenv directories.
~/src — The source for the project contained herein; the package
folder, where the setup.py lives.
~/usr/src — Optional related source packages go here; e.g. trunk
checkouts of dependancies.
~/var/{log,run} — Log files and runtime files (PIDs, sockets, etc.)
useful for web apps more than other projects.
> You might be interested in virtualenvwrapper:
> http://www.doughellmann.com/projects/virtualenvwrapper/. It lets you
> do things like `$ workon MyProj` instead of `$ cd MyProj; source bin/
> activate`.
I have macros set up for working on my virtual environments. *loves
her Zsh*
— Alice.
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"pylons-discuss" 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/pylons-discuss?hl=en
-~----------~----~----~----~------~----~------~--~---
