On 2012-11-20 02:00:34 +0000, Tres Seaver said:
-----BEGIN PGP SIGNED MESSAGE-----
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 <[email protected]>
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].
Alex
[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 [email protected]
Palladion Software "Excellence by Design" http://palladion.com
-----BEGIN PGP SIGNATURE-----
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
-----END PGP SIGNATURE-----
_______________________________________________
Distutils-SIG maillist - [email protected]
http://mail.python.org/mailman/listinfo/distutils-sig
--
Alex Clark · https://www.gittip.com/aclark4life/
_______________________________________________
Distutils-SIG maillist - [email protected]
http://mail.python.org/mailman/listinfo/distutils-sig
