homepage

The Quick Start section in the devguide does not tell people what they need to install in order to compile Python. A short mention or a link to a section with all info should be added.
I can contribute info for Debian and derivative systems: "aptitude build-dep pythonX.Y"

Well, it's a quick start. The link to "build Python" actually tells you about dependencies.

Okay. I just hope that people following the quick start and having build issues will follow the link.
I followed it and the section only mentions zlib, I think it could be exhaustive.

I agree with Antoine, there's no need to mention them in the quickstart. Moreover these dependencies are optional, so there's no need to install them unless they are specifically needed (on a related note I would also add an "optional" in the warning that says "Python build finished, but the necessary bits to build these modules were not found" -- I've seen enough people complaining that the build "failed" because this dependencies were missing).
Explaining how to get them in the build page sounds fine to me.

> Moreover these dependencies are optional, so there's no need to install them unless they are
> specifically needed
I think about it in the reverse: You want a featurefull library, and disable some things (zlib, ssl, threads) only if you specifically don’t want them (if you’re a Twisted fan for example <async wink>).
> (on a related note I would also add an "optional" in the warning that says "Python build
> finished, but the necessary bits to build these modules were not found" -- I've seen enough
> people complaining that the build "failed" because this dependencies were missing).
Sure. I read all changesets for Python’s setup.py recently (don’t judge) and the addition of this message and further edits to its wording were done exactly to avoid people worrying that their python binary is not usable.
> Explaining how to get them in the build page sounds fine to me.
Okay; do we need to collect info for all major OSes (I’m taking the list of stable 3.2 buildbots to determine "major")?

> I think about it in the reverse: You want a featurefull library, and 
> disable some things (zlib, ssl, threads) only if you specifically 
> don’t want them (if you’re a Twisted fan for example <async wink>).
I have a few arguments in favor of my position:
1) Python and its test suite should always run without errors, even when some dependencies are missing (I've found and fixed several issues related to zlib because it was missing here);
2) The default Python installed with the OS will use whatever dependencies are already provided, so if you add all the missing ones manually, you'll be testing in a scenario that is different from the "default" one (you might argue that if no one installs all the missing dependencies, we can't know if they all work together everywhere (IIRC at some point we had a discussion about having a buildbot without the optional dependencies too));
3) Hard work pays off later. Laziness pays off now!
> the addition of this message and further edits to its wording were done
> exactly to avoid people worrying that their python binary is not usable.
But it's still missing an "optional" before modules imho. The second message that says to "look in setup.py in detect_modules()" doesn't seem too useful too (but maybe I should take a look ;). There are a couple of threads on Core-Mentorship by people that got confused by these messages (and some include discussions about finding the dependencies).
> Okay; do we need to collect info for all major OSes
> (I’m taking the list of stable 3.2 buildbots to determine "major")?
You can also do it incrementally, adding e.g. "For Debian and derivative systems you can use ``aptitude build-dep pythonX.Y``." and then add other items to the list as soon as we figure them out (you can also try to figure them out in advanced, as long as finding the command for some obscure platform doesn't keep on hold the list of commands for other well known platforms).

> I have a few arguments in favor of my position:
Hm, I said that people wanted a "feature-full library" but I was confused: We’re talking about a Python built for contributing, not to develop your app, so my argument does not apply. So, the devguide should list the optional build deps *and* say something like "these are not needed to run Python and its test suite, but you may need one them of for some patches".
> (I've found and fixed several issues related to zlib because it was missing here)
I know :) I have a Python built without threads and run packaging and distutils tests with it from time to time, but it seems I can’t disable zlib at configure time.
>> the addition of this message and further edits to its wording were done
>> exactly to avoid people worrying that their python binary is not usable.
> But it's still missing an "optional" before modules imho.
What I meant is that the history of this messages says that you can just go ahead and add "optional".
> The second message that says to "look in setup.py in detect_modules()" doesn't seem too
> useful too (but maybe I should take a look ;).
It is scary code.
>> Okay; do we need to collect info for all major OSes
> You can also do it incrementally
Okay, I’ll make a patch.

So, the devguide has been updated since this issue was opened. The Quick Start section now has a link to build documentation, which includes information about build dependencies. Is this sufficient to call this bug closed?

I agree with Jeff's recommendation that this issue is resolved by content already in the devguide's Build Dependencies[1].
Jeff, Thanks for helping close an old issue.
[1] https://docs.python.org/devguide/setup.html#build-dependencies