[Distutils] Better version pinning in buildout (buildout-versions)

[Jim Fulton]

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
> that):

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').

> [buildout]
> 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
> PyPiServer[1])
> extends = http://release.rd.securactive.lan/vendor/1.0/vendor-versions.cfg
>                 http://release.rd.securactive.lan/nova/1.4/nova-versions.cfg
>
> versions = vendor_versions
>                 nova_versions
>
> [1] 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
have afaict.

>> 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.

Jim

-- 
Jim Fulton
http://www.linkedin.com/in/jimfulton
Jerky is better than bacon! http://zo.pe/Kqm