[PATCH 2 of 2] httpclient: import revision fc731618702a of py-nonblocking-http

[Matt Mackall]

On Wed, 2011-05-18 at 07:54 -0500, Augie Fackler wrote:
> On May 18, 2011, at 4:24 AM, Martin Geisler wrote:
> > 
> > Matt Mackall <mpm at selenic.com> writes:
> > 
> >> On Tue, 2011-05-17 at 13:36 -0500, Augie Fackler wrote:
> >>> # HG changeset patch
> >>> # User Augie Fackler <durin42 at gmail.com>
> >>> # Date 1305646083 18000
> >>> # Node ID 886fed778423d4dfc0f95fd7684a0c144cd934a5
> >>> # Parent  8689945a9491d807e3a7154c544166a82423efa3
> >>> httpclient: import revision fc731618702a of py-nonblocking-http
> >> 
> >> These are queued, thanks.
> > 
> > I think we should think about making the httpclient a subrepo.
> 
> You can't do that given the current structure - py-nonblocking-http is
> its own project, and as such the repo root isn't the python module
> root. I'm also highly resistant to changing py-nonblocking-http's
> layout, as there's likely to be more scaffolding in there as I get
> good end-to-end comprehensive tests written.

If we were to do this, it'd be structured like this:

mercurial-and-dependencies/
  Makefile  <- whatever glue logic is required
  mercurial/  <- our current repo, without the httpclient/
  py-nonblocking-http/ <- your current repo, as is
  ...

..so the details of your project's layout wouldn't really matter.

(And the rest of this is addressed to Martin..)

The thing is, I would stop using this "super-repo" as soon as
py-nonblocking-http was mature enough that it had it's got version
numbers, releases, and Debian packages. Then it would be on par with
other things we use but generally don't even need to think about like
OpenSSL and libc. Hopefully that day is not far off and we can drop
httpclient/.

A sensible open source application does not bundle its dependencies nor
depend on precise versions of its dependencies. This just makes extra
pain for integrators and packagers who have to then decouple things or
face dependency hell. Doing it this way:

mercurial/
  py-nonblocking-http/

..would probably be completely broken in a world where I can apt-get
py-nonblocking-http. My local version would collide with the system
version and make building challenging. Given that we -don't want to care
which version we have-, there's no upside here.

Here's how Mercurial's dependencies are specified in its Debian binary
package:

Depends: libc6 (>= 2.4), python (<< 2.8), python (>= 2.6),
python-support (>= 0.90.0), ucf (>= 2.0020), mercurial-common (=
1.8.3-1)
Suggests: qct, wish, vim | emacs, kdiff3 | tkdiff | meld | xxdiff
Breaks: mercurial-git (<< 0.2.6)

(It only depends on python > 2.6 because it actually contains the
extensions compiled against that version. ucf is some generic
configuration migration helper code.)

And mercurial-common (the arch-neutral bits):
Depends: python (>= 2.4), python-support (>= 0.90.0)
Recommends: mercurial (>= 1.8.3-1), ca-certificates
Suggests: wish, python-mysqldb, python-pygments, python-openssl
Breaks: mercurial (<< 1.8.3-1)

I think in the future, python-non-blocking-http will also be in these
lists (like pygments, with no version number!), but under the
"Recommends:" category. That is, if not present, we'll fall back to
Python's crummy built-in support.


So if it doesn't make sense to use subrepos for an open-source package
like Mercurial, what does it make sense for? The answer is managing
platforms and distributions.

For instance, TortoiseHG ships an entire self-contained hg world along
with itself because there's no dependency management architecture on
Windows. So here it's meaningful for a packager (ie Steve) to be able to
track the precise versions of everything he ships. So he could set up a
repo like:

thg-windows-build/
  Makefile  <- build glue
  tortoisehg/
  mercurial/
  py-nonblocking-http/
  ...

Then when he does a release build, he could tag the build repo to record
what component versions made it into the build.

Similarly, people who are managing websites with multiple third-party
components and want reproducibility of precise combinations should do
something similar. But as a project, we -don't- want to be dependent on
precise versions and we -don't- ship bundles of third-party components.
So subrepos are a boat anchor we don't want to lug around.

And we -also- don't want random open-source projects to follow our lead
in using boat anchors where inappropriate.

So no: it continues to be inappropriate to dog-food this feature, just
as it is inappropriate for us to dogfood keywords and eol.

-- 
Mathematics is the supreme nostalgia of our time.