I'm of two minds as to what you are asking. 1. For components that don't have a version sepcification, buildout *normally) checks to see if there is a newer version available, and, if there is installs it in place of the existing version (doesn't necessarily delete the files for the old version, just removes it from your python path).
You can avoid this by using the -N command line swtich. (That capital N, small n is the default behavior.) I use this a lot. In the land of plone developemnt I wind up needing to re-run buildout fairly often, but don't want my downloaded stuff upgraded. You can still upgrade a single package by deleting (or moving) it's egg (or other installed footprint) and running buildout -N. It will see that it doesn't have a package for the requirement, and install one. Note that specifying a new version number for a component is not enough to get it changed if you use -N. -N says "If I have some version of a requirement already, use it". But if you delete a newer version of apackage, you can use version specifiers to go back to an older version, for example. I'm not absolutely sure how this interacts with stuff pulled from a version control system, rather than from pypi or wherever as a tarball or egg. 2. If you are editing the stuff that buildout downloaded, yes, that can get trashed. Eggs won't get downloaded until there is a newer version available, but that becomes a time bomb. If you are doing a serious fork, then you want to look at development eggs. That's typically placed in a subdirectory in egg format of the src subdirectory of the directory containing buildout.cfg. You list the egg name in your buildout:eggs value, and the relative path to the egg in the buildout:develop value. For example: [buildout] eggs = your other eggs your_development_egg develop = src/your_development_egg What all this does is make buildout include src/your_development_egg/your_deveolpment_egg (remember, this is egg format) in your path, but it makes no assumptions about being able to get versions of your project from somewhere. (setup.py of your egg probably gets run, but you can probably no-op it. There are probably some paster scripts that will make you an empty egg structure - the ones for plone probably run a little deeper than you want, unless you need to take advantage of namespace packages.) So you check the code out into the directory that gets added to the path, and go to town. buildout won't run a svn update there, for example. 2a. Another, less savory, but more convenient approach that I have sometimes taken is to add a file in an automatically downloaded egg (or equivalet) to my top level (directory with buildout.cfg) mercurial repository, about which buildout (at least so far) knows nothing. It might also live in a svn repository (I have that situation exactly), which works fine, so long as you add a regexp pattern to .hgignore to exclude the .svn directories (and likewise, make svn ignore the .hg and .hgignore files at the top level, if the svn checkout is rooted at or above the same directory). Then just make sure that your changed files are checked into mercurial before running buildout, and you can revert them afterwards. Bill On Tue, Mar 16, 2010 at 3:32 PM, John Griessen <j...@industromatic.com> wrote: > If you run buildout it checks out what you made changes to -- wiping the > changes. > Am I supposed to be using any particular version control with buildout? It > seems > to mention many kinds. > > So, my buildout.cfg looks like: > > [buildout] > eggs-directory = /home/john/buildout/eggs > extensions = mr.developer > sources = sources > auto-checkout = django-mptt > > parts = > django > > eggs = > mock > django-notification > django-page-cms > django-haystack > > [sources] > django-mptt = svn http://django-mptt.googlecode.com/svn/trunk/ > path=django-mptt > > [django] > recipe = djangorecipe > version = 1.1.1 > settings = development > urls = > > > http://code.google.com/p/django-messages/source/browse/#svn/branches/messages-0.4.x > > wsgi = true > eggs = ${buildout:eggs} > project = cottagematic_com > > > Should my project go under sources? > Should I start using svn or git on my project dirs and add and commit? > (trying this next) > > thanks, > > John > > -- > You received this message because you are subscribed to the Google Groups > "Django users" group. > To post to this group, send email to django-us...@googlegroups.com. > To unsubscribe from this group, send email to > django-users+unsubscr...@googlegroups.com. > For more options, visit this group at > http://groups.google.com/group/django-users?hl=en. > > -- You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-us...@googlegroups.com. To unsubscribe from this group, send email to django-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-users?hl=en.
