On 2012-11-19 16:36:28 +0000, Jim Fulton said:

On Mon, Nov 19, 2012 at 11:30 AM, Jim Fulton wrote: ...

...

Since this is still an alpha release, you'll need to supply the -y

Sorry, -t option.

Well it appears to be very fast, congrats! :-) Here's `buildout init` in 1.6.3 vs. 2.0.0a4: - bin/buildout init 1.18s user 0.20s system 48% cpu 2.874 total (Buildout 1.6.3) - bin/buildout init 0.21s user 0.06s system 96% cpu 0.274 total (Buildout 2.0.0a4) Also noticed case-sensitivity in recipe names, which IIRC was not there before. However, I wonder if you'd consider "hiding" (on PyPI) the alpha releases until we can make sure 2.0.0 works in most cases where 1.6.x does?

Jim

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

On 2012-11-19 22:08:59 +0000, Jim Fulton said:

On Mon, Nov 19, 2012 at 4:57 PM, Alex Clark wrote: ...

...

Well it appears to be very fast, congrats! :-) Here's `buildout init` in 1.6.3 vs. 2.0.0a4:

- bin/buildout init 1.18s user 0.20s system 48% cpu 2.874 total (Buildout 1.6.3) - bin/buildout init 0.21s user 0.06s system 96% cpu 0.274 total (Buildout 2.0.0a4)

That's cool. Wasn't me. :)

...

Also noticed case-sensitivity in recipe names, which IIRC was not there before.

Nothing's changed there AFAIK.

...

However, I wonder if you'd consider "hiding" (on PyPI) the alpha releases until we can make sure 2.0.0 works in most cases where 1.6.x does?

To what end?

If you don't hide the alpha, then "{easy_install, pip install} zc.buildout" installs the alpha, which is not what most people want; as it currently breaks things. E.g. I made this change this a.m. in order to be able to keep working: - https://github.com/aclark4life/binfiles/commit/eda7b0271cbbd2943a619aac77965...

AFAIK, there's no harm in having buildout 2.0.0a4 unhidden. We've had earlier alphas out there for years.

The earlier alphas were/are all hidden (because the exact same thing happened last time, IIRC).

Buildout 1 (1.4 and later) won't upgrade itself to buildout 2, nor will it use zc.recipe.egg 2. Furthermore, hiding the release won't hide it from buildout, since buildout uses the simple index by default and no releases in the simple indexes (or replicas) are hidden.

This won't be an issue until buildout 2 final. By then, I hope we'll add logic to 1.6 to prevent upgrading above 1.

No idea about upgrades, or hiding Buildout from Buildout :-).

Jim

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

On Mon, Nov 19, 2012 at 5:41 PM, Jim Fulton wrote: ...

I've removed the buildout alpha from pypi.

It's available here: https://github.com/downloads/buildout/buildout/zc.buildout-2.0.0a4.tar.gz The bootstrap script will have to be hacked to pull the release from there. Of course, if people used the bootstrap.py script from their virtualenvs, rather than pip, they wouldn't have had a problem. Jim -- Jim Fulton http://www.linkedin.com/in/jimfulton Jerky is better than bacon! http://zo.pe/Kqm

On Monday, November 19, 2012 at 6:00 PM, Alex Clark 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). I also wonder if that is the right thing to do. 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

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

pip does do something differently when an exact version is given. It looks at: 1. '(index_url)s/%(project_name)s/%(version)s' 2. '(index_url)s/%(project_name)s' 3. '(index_url)s' It stops on the first page it finds. Crate.io uses this in order to allow packages to never get deleted, but deleted packages only install if you've pinned exactly to that version. I don't know if Buildout or easy_install do anything similar as I don't use them.

Alex

...

Jim

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

_______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org (mailto:Distutils-SIG@python.org) http://mail.python.org/mailman/listinfo/distutils-sig

On 11/19/2012 06:19 PM, Jim Fulton wrote:

On Mon, Nov 19, 2012 at 6:00 PM, Alex Clark 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. - C

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 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 tseaver@palladion.com 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 - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig

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

On 2012-11-20 03:21:38 +0000, Chris McDonough said:

On 11/19/2012 09:47 PM, Alex Clark wrote:

...

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

...

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

Whom is it actually breaking? People who do "easy_install zc.buildout"? For people who aren't trying to install it for the first time and whom already have it, isn't this what:

[versions] zc.buildout = 1.5.2

is for?

Well, it broke for me: - https://github.com/aclark4life/binfiles/commit/eda7b0271cbbd2943a619aac77965... And cullerton: 19:43 < cullerton> Folks, there's something wonky going on with buildout this morning. When I run bootstrap, it creates a buildout script using buildout 2.0. 0a4. This fails with an error (TypeError: get_dist() takes exactly 4 arguments (3 given)). Changing the version to buildout 1.4.4 seems to fix things. 19:43 <@aclark> cullerton: 2.0.0a4 is out 19:43 <@aclark> cullerton: use 1.6.3 19:43 < cullerton> is there a way to pin that when running bootstrap? 19:43 <@aclark> cullerton: (I've already asked jim if we can hide 2.0.0a4) 19:45 < cullerton> aclark: thanks But yeah, in theory I guess that is what pinning the version in buildout.cfg is for. Actually, pinning versions in Buildout is much more straightfoward IMHO when you aren't pinning Buildout itself (at which point you may encounter the somewhat awkward self-re-bootstrap). Jim may have better thoughts on how this is supposed to work at a high level. Alex

- C

_______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig

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

On 15/12/2012 09:33, Lele Gaifax wrote:

Alex Clark writes:

...

19:43 < cullerton> Folks, there's something wonky going on with buildout this morning. When I run bootstrap, it creates a buildout script using buildout 2.0. 0a4. This fails with an error (TypeError: get_dist() takes exactly 4 arguments (3 given)). Changing the version to buildout 1.4.4 seems to fix things.

FYI, I just met the same error (using 2.0.0a5), and the culprit was the buildout.dumppickedversion extension, that monkey-patches the easy_install.py::Installer._get_dist() method (it surprised me at first that the error message mentions “get_dist()” but at the referenced line in easy_install.py there is a call to “_get_dist()”...). It took a pdb session and a “p inspect.getmodule(self._get_dist)” to find out what's going on.

Yeah, the stuff that buildout.dumppickedversions and buildout_versions provide should just be in the core. Jim, if I worked up a pull request would you merge it? cheers, Chris -- Simplistix - Content Management, Batch Processing & Python Consulting - http://www.simplistix.co.uk