Encouraging best practices through server communication
Gregory Szorc
gregory.szorc at gmail.com
Tue Dec 10 10:41:50 UTC 2013
From my experience observing dozens of developers work on a large
Mercurial project (Firefox), it's increasingly apparent to me that a
large chunk of Mercurial users are failing to harness some of the basic
features of Mercurial, much less adopt some of the "advanced" practices
we prescribe for Firefox development (including a slew of custom
extensions).
While I think the out-of-the-box Mercurial experience could be more
proactive about certain features (e.g. more UX only extensions like
color and pager enabled by default, "advertisements" about related
commands and functionality, etc), there are scenarios where vanilla
Mercurial alone doesn't know about best practices. For example, let's
say you have written a custom Mercurial extension to make interacting
with your repo better. It provides custom hooks to ensure linting before
push, etc. You /really/ want people to install it because it's so
awesome and makes your code better. Unfortunately, getting the message
out through traditional channels is hard (say it's a large, distributed,
open source project). What other methods are available to us?
I put together a "best practices" Mercurial extension [1] to try to
solve this problem. Essentially, the server detects when clients don't
have this extension installed and alerts them to install it. When a
client has the extension installed, it asks the server to describe its
recommended best practices. The server sends down some metadata (minimum
client version, what extensions to have installed, etc) and the client
self-checks its conformance and notifies/prompts about "violations." The
client can even auto-install extensions from the repo URLs specified by
the server! Effectively, the server prescribes a set of best practices
for interacting with it and the client helps the user achieve that state.
While the extension isn't finished and has yet to be deployed outside of
testing, I thought I'd share it with this list for a few reasons. First,
I think people may find it interesting. Second, I have technical
concerns/questions about the implementation. There are a number of
aspects of the implementation that feel too hacky to me. There is also
functionality not possible with Mercurial today (mainly due to the wire
protocol design). I'd like to have a discussion about supporting these
use cases in a future Mercurial release. Notably:
* Client doesn't self-advertise capabilities like servers do. It would
be cool if servers could proactively sniff for missing capabilities and
be like "upgrade your Mercurial install!"
* Passing messages for user display from server to client is not well
supported. Only some commands have their output sent to the client. I
would like a dedicated "band" in the protocol for transporting messages
back to clients for *any* command. I think allowing servers to
"advertise" message of the day or such on pull could be very useful.
* Possibly a superset of the above - it's not possible to exchange
arbitrary metadata as part of client-server communication. My extension
would be much, much easier if every command request and response could
have arbitrary (key-value?) metadata attached to it.
Is there any interesting in pursuing these features? Do people think my
extension has wheels?
[1] https://bugzilla.mozilla.org/show_bug.cgi?id=941856
Gregory Szorc
gregory.szorc at gmail.com
More information about the Mercurial
mailing list