search

felipec / git-remote-hg

Transparent bidirectional bridge between Git and Mercurial for Git
GNU General Public License v2.0
369 stars 87 forks source link

ImportError: No module named mercurial: Clarify install documentation #52

Closed nealmcb closed 8 years ago

nealmcb commented 8 years ago

To install git-remote-hg, I followed the simple wget-based instructions at felipec/git-remote-hg: Transparent bidirectional bridge between Git and Mercurial for Git

But when trying to run it I encountered this error.

Cloning into 'bx-python'...
Traceback (most recent call last):
  File ".../git-remote-hg", line 15, in <module>
    from mercurial import hg, ui, bookmarks, context, encoding
ImportError: No module named mercurial

Some googling led me to a bunch of different advice and potentially complicating issues, like #38 and #27. Especially after an initial failure, I hate having to try different things, and prefer a robust solution.

I think the main page should clarify at least one clean, known-to-work scenario.

In my case (Ubuntu Trusty), I know it is generally better for long-term security to install official packages, and it seems to have worked to do apt-get install mercurial. For others it might be more appropriate to install via pip from git-remote-hg 0.1.1 : Python Package Index.

felipec commented 8 years ago

I don't understand why anybody would think that Mercurial wasn't needed. But it's mentioned now. b6e9475.

fingolfin commented 8 years ago

Why wouldn't they? There are several reimplementations of git from scratch; for an outsider, who knows nothing about the internals of Mercurial and Git, it is conceivable that git-remote-hg is fully self-contained.

felipec commented 8 years ago

A single script that is 1k lines long implements Mercurial internals. Yeah. Sure.

fingolfin commented 8 years ago

Note the "for an outsider". To somebody who just uses git and mercurial, but has no clue as to how they work internally, or how different/similar their respective internals are, it is conceivable that a very simple "conversion script" is all that is needed. Alternatively, the script might automatically pull in whatever other requirements it has.

Of course for anybody who knows a bit more about the details would expect that Mercurial is a requiement. But if you follow that train of thought, you can stop writing any documentation and expect user's to know exactly as much about a given piece of software as its author.

felipec commented 8 years ago

The script should be distributed with Git, and packaged by distributions, the user shouldn't need to do anything. It's not my fault the Git project chose to make it difficult to the users.

fingolfin commented 8 years ago

Even if it was bundled was git, then the dependency on hg should still be documented by the exact same argument.

[Offtopic, but: I would argue (and am sure many people on the git mailing list would agree) that it is your fault that this script is not distributed with Git. ]

felipec commented 8 years ago

git-remote-bzr requires Bazaar, git-svn requires Subversion, git-p4 requires P4, git-remote-mediawiki requires Mediawiki. Packagers already know that.

nealmcb commented 8 years ago

Thanks for clarifying the requirement. I just think these days it is a standard, helpful thing to document requirements for software, especially when search engines lead to confusing histories. Cheers.