On Mon, Jan 7, 2013 at 8:58 PM, Sebastien Douche <sdou...@gmail.com> wrote: > On Sat, Jan 5, 2013 at 11:47 PM, Jim Fulton <j...@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 _______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
