Marius Gedminas

> Installs parts X, Y, Z, and their dependencies and uninstalls anything else that was previously installed. Ouch, ouch, ouch, I didn't realize it would uninstall all the other parts!

I remember pull requests adding offline mode to bootstrap.py. I don't remember if they were accepted or if they had any documentation. (Everything is terrible and I'm very sorry.)

Besides, people can always use ./~ to refer to local directories named ~.

I don't see any documentation for this, or tests either.

It took me a while to understand why the existing `extensions` option couldn't be used for this. (It enumerates Python packages, that is, distributions, and each of those might conceivably...

While zc.buildout's documentation is not stellar, extensions are documented: https://pypi.python.org/pypi/zc.buildout/2.2.1#extensions The source for that documentation is https://github.com/buildout/buildout/blob/08c34b844c049cff11ef98c6cf9e516de90cf592/src/zc/buildout/buildout.txt#L3031 As for tests, I agree that doctests are hard to modify. Creating a...

You can use `bin/buildout update-versions-file=versions.cfg` to do that. This requires some initial setup: 1. add `extends = versions.cfg` in your `buildout.cfg` 2. create an empty `versions.cfg` with just `[versions]` at...

> The worst that can happen is if the installed packages come already with their own badly built .pyc files that would report the paths incorrectly in Python tracebacks, but...

It was always my impression that ${buildout:directory} was a readonly variable containing the directory that contains the buildout.cfg, so you could use it if you needed to provide an absolute...

Can't you get what you want by saying `parts += base2` in base2.cfg? Personally, I find such implicit concatenation unintuitive. What happens if both base1.cfg and base2.cfg say `newest =...