[Distutils] zc.buildout 2.0.0a4 released

Alex Clark aclark at aclark.net
Tue Nov 20 03:47:21 CET 2012

On 2012-11-20 02:00:34 +0000, Tres Seaver said:

> Hash: SHA1
> On 11/19/2012 07:16 PM, Chris McDonough wrote:
>> On 11/19/2012 06:19 PM, Jim Fulton wrote:
>>> On Mon, Nov 19, 2012 at 6:00 PM, Alex Clark <aclark at aclark.net>
>>> wrote:
>>>> Ugh, sorry. I wonder if we can get Richard Jones or Martin von
>>>> Löwis to modify PyPI such that "hiding" really means hiding
>>>> (CC'ing catalog-sig).
>>> That would be very bad.  Old releases are often hidden.
>>>> I also wonder if that is the right thing to do.
>>> It's not.
>>>> Personally, I'd be OK with having to use find-links (or something
>>>> like it) to test the alpha e.g.:
>>>> $ pip install -f http://path/to/buildout.zip zc.buildout
>>> pip install
>>> https://github.com/downloads/buildout/buildout/zc.buildout-2.0.0a4.tar.gz
> Actually what would be ideal (I think), if it were possible, is:
>>>> - Upload sdist - Hide release - pip install zc.buildout installs
>>>> latest unhidden release - pip install zc.buildout==2.0.0a4
>>>> installs 2.0.0a4.
>>>> But that may be nonsensical… unless perhaps pip and easy_install
>>>> were to check a different index if/when an exact version spec is
>>>> given. :-/
>>> What would be ideal would be for pip and easy_install to only
>>> install non-final releases if asked to. Or at least provide an
>>> option to prefer final releases. Buildout has had a prefer-final
>>> option for years. In an upcoming buildout 2 alpha, this will become
>>> the default.
>> My $.02: PyPI consumers are not customers.  They are collaborators.> 
>> They are collaborators who need to be paying active attention to what
>> they're doing if they choose to install random stuff from PyPI.
>> Doubly so if they're automating that installation.  Triply so if the
>> automated installation of a system must not break because they'll lose
>> time or money or both as a result.
>> There is no sense in ever making an alpha release if it's never going
>> to be installed by anybody.  I agree that preferring final releases
>> should probably be the default for installer tools.  However, even if
>> it's not, distribution creators shouldn't feel compelled to hold off
>> pushing an alpha release to PyPI for fear that someone might actually
>> use it.
> Amen.  Let's not coddle folks who blindly install without checking, to
> the detriment of those who pay attention and will help find and fix bugs.
>  Those who need the coddling should be paying somebody for the service.

I agree on principle something like the zc.buildout 2.0 alpha should go 
to PyPI so folks can start using, testing, giving feedback, etc. But I 
don't agree in practice it is the right thing to do when we know it is 
going to negatively affect a large number of users[1].


[1] My reasons are selfish: I had one "buildout is broken" question in 
#plone today. And I was expecting many more to come. I also don't agree 
that consumers are *just* collaborators. Anyone unfamiliar with Python 
that types `{easy_install, pip install} <something>` has the expection 
that <something> will deliver on whatever promise it made. As 
collaborators, if we fail to help make that promise come true, then we 
are failing Python in general, IMHO.

> Tres.
> - 
> --==================================================================Tres 
> Seaver          +1 540-429-0999          tseaver at palladion.com
> Palladion Software   "Excellence by Design"    http://palladion.com
> Version: GnuPG v1.4.11 (GNU/Linux)
> Comment: Using GnuPG with Mozilla - http://www.enigmail.net/
> iEYEARECAAYFAlCq5EIACgkQ+gerLs4ltQ687QCfSJiejVQS+76cdA/o7gLT7h/Y
> EkgAoL6EsKMfB9Yi96Sy4r/3Ovv0/yJu
> =Y24e
> _______________________________________________
> Distutils-SIG maillist  -  Distutils-SIG at python.org
> http://mail.python.org/mailman/listinfo/distutils-sig

Alex Clark · https://www.gittip.com/aclark4life/

More information about the Distutils-SIG mailing list