2.3 upgrade notes: remote repository API
Matt Mackall
mpm at selenic.com
Mon Sep 17 17:33:57 CDT 2012
On Tue, 2012-09-18 at 00:08 +0200, Arne Babenhauserheide wrote:
> Hi Matt,
>
> Am Montag, 17. September 2012, 13:36:24 schrieb Matt Mackall:
> > http://mercurial.selenic.com/wiki/MercurialApi#Why_you_shouldn.27t_use_Mercu
> > rial.27s_internal_API
> >
> > ..more or less sums up why this is out of scope for UpgradeNotes.
> >
> > I think the next step I'm going to take is to start actively denying the
> > import of Mercurial modules unless you set:
> >
> > iacknowledgethatmercurialisnotalibraryandishouldntdependonitsinternals =
> > True
>
> So, what can I do if I wrote an extension which provides some functionality
> for which I need to be able to hook into internal functions?
>
> hggit, hgsubversion, staticsite and infocalypse are examples.
>
> How can I make it less likely that they get broken by a hg update?
Depend on fewer (preferably no) internals.
Yes, I know that hggit and the like are basically impossible to
implement without mucking about in Mercurial's internals. Their
collateral breakage when Mercurial internals evolve _is the price you
have to pay for that level of access_.
None of this is news from this decade, folks.
--
Mathematics is the supreme nostalgia of our time.
More information about the Mercurial-devel
mailing list