[Distutils] Better version pinning in buildout (buildout-versions)
jim at zope.com
Tue Jan 8 13:08:25 CET 2013
On Mon, Jan 7, 2013 at 8:58 PM, Sebastien Douche <sdouche at gmail.com> wrote:
> On Sat, Jan 5, 2013 at 11:47 PM, Jim Fulton <jim at zope.com> wrote:
>> 1. New buildout option named ``versions-file`` which takes the name of
>> a file. to contain version information.
> Multi version files will be a great improvement. Currently It's a pain
> to configure more than one KGS (I mix find-links and pinning to do
This proposal is meant to be orthogonal to KGSs. I don't
see how multiple version-files would benefit, unless you mean
evaluating them at multiple extends levels (which is possible
and would mitigate a concern of Marius').
> index = http://pypi.rd.securactive.lan/
> find-links = http://release.rd.securactive.lan/vendor/1.0/links.html
> extends = nova-versions.cfg
> versions = nova_versions
> To summarize:
> - pypi.rd.s.lan list our packages.
> - find-links point on vendor KGS site (list of vendor packages with
> the right versions, no needing pinning).
As long as there aren't duplications and
as long as none of the packages are in your index.
> - we use pinning only for our packages
> It works but it's not ideal (must use zope.kgs). I would something like that:
> index = http://pypi.rd.securactive.lan/ (fallback to the PyPI, cf
> extends = http://release.rd.securactive.lan/vendor/1.0/vendor-versions.cfg
> versions = vendor_versions
>  http://pypi.python.org/pypi/pypiserver/
I don't follow this. It's more complicated and doesn't
seem to provide any capability you don't already
>> 3. The ``allow-picked-versions`` option gets a new allowed value of
>> ``warn``. if there are unpicked versions and this option is set to
>> ``warn``, then picked/unpinned versions are reported. Also, if
>> ``allow-picked-versions`` is true, there will be no error if
>> ``update-versions-file`` is true.
> When I code I want new version of our packages (sact.*) but not the
> vendor packages. A pattern of list would be very useful (ex:
> allow-picked-versions = sact.*)
ok, but that's outside the scope of this proposal, which is
largely to incorporate functionality from buildout-versions.
>> 4. New buildout option: ``python-version`` that restricts the Python
>> version, with the same semantics as buildout-version provides now.
> Don't see the point, Buildout launch the Python version used by the
> bootstrap process.
I think the rational for this is well described elsewhere in this thread.
Jerky is better than bacon! http://zo.pe/Kqm
More information about the Distutils-SIG