Hi All,
My take on this, as the person who may or may not have offered to do the
work...
After reading all the discussion, it sounds like the approach
buildout-versions currently takes is the one that's going to give the
most milleage:
- print the versions picked for any packages (as opposed to being
specified by the buildout), in a format compatible with being pasted
into buildout.cfg's versions section. This should happen by default.
(when *wouldn't* you want this to be shown?)
- have a key that points to a file where the text above is appended.
It's up to the use whether this is buildout.cfg or not. For myself, if
the buildout is tiny, I put a versions section at the end and point this
option at buildout.cfg. Otherwise, I point it as a versions.cfg.
I had forgotten how important the interaction between the versions
section and the extends mechanism was. I've also made great use of this.
While I like the idea of a versions format compatible with pip*, it
sounds like that would kill off the extends interaction, which would be bad.
I'll note that there appears to be no contention over the optional
python-version key to stop you accidentally running a buildout with the
wrong python.
cheers,
Chris
* I have to admit to currently thinking hard about migrating away from
buildout; its development has been hampered by people with not enough
time trying to solve hard problems, the dropping of Windows support
(yeah, I hate windows too, but its still used enough that I need to
support it, unfortunately I'm not competent enough to help with
development *of* buildout on Windows). That said, I don't know that
pip/virtualenv would be any better.
--
Simplistix - Content Management, Batch Processing & Python Consulting
- http://www.simplistix.co.uk
_______________________________________________
Distutils-SIG maillist - [email protected]
http://mail.python.org/mailman/listinfo/distutils-sig
