On Fri, 19 Jul 2024 14:28:57 +0200 (CEST) PIERRE AUGIER <pierre.aug...@univ-grenoble-alpes.fr> wrote:
> I first wanted to react to a statement on Mercurial wheels on PyPI > and it leads me to express my fear that Mercurial is not evolving > towards a nice alternative to Git. > > I describe few issues and try to think about what could be done to > fix them. > > ----- Mail original ----- > > De: "Alessandro Dentella" <sandro.dente...@gmail.com> > > À: "Uwe Brauer" <o...@mat.ucm.es>, "mercurial" > > <mercur...@mercurial-scm.org> Envoyé: Vendredi 19 Juillet 2024 > > 09:36:14 Objet: Re: ubuntu 24 (and most likely debian 12) does not > > allow to install evolve > > > Il giorno gio 18 lug 2024 alle ore 16:45 Uwe Brauer via Mercurial < > > [ mailto:mercurial@lists.mercurial-scm.org | > > mercurial@lists.mercurial-scm.org ] > > > ha scritto: > > > > II don't really know which version of hg-git is ok for you, but I'm > > on Ubuntu 24:04 and I can tell you that 67.2 is the default that in > > fact does not work with evolve, so Idid exactly what was suggested > > by Sietze Browser:: > > > > sudo apt install pipx > > pipx install mercurial > > pipx inject mercurial hg-evolve hg-git > > > > and I ended up with:: > > > > mercurial 6.8 > > hg-git 1.1.3 > > evolve 11.1.4 > > > > do you need something different? > > It was very fast as it uses wheels > > Unfortunately, there is no Mercurial wheels on PyPI (see > https://pypi.org/project/mercurial/#files)! I don't know any other > big public open-source Python projects using extensions that do not > upload wheels on PyPI. Nowadays, it is very simple. > > Even if I don't like it, I have to admit that it becomes more and > more difficult to defend Mercurial. I start to feel that it does not > make sense to teach Mercurial anymore. I see two main issues: > > 1. Setting up Mercurial with basic extensions (topics, hg-git, > evolve) is TOO difficult and long for beginners (in particular > compared to Git). > > Python packaging is improving but Mercurial does not follow. > Installation via pipx really makes sense for Mercurial and its > extensions. > > > pipx install mercurial > > pipx inject mercurial hg-evolve hg-git > > should work **without compilation** (i.e. without Python headers and > compilers) basically everywhere/everytime (of course on > up-to-date/standard platforms with an up-to-date python). It should > be checked that these commands lead to something reasonable on recent > Windows, macOS and popular Linux distros. For example, on Windows, I > thing there is by default neither vi nor any pager. Mercurial should > be aware of that and at least print reasonable advice when such > issues are detected. > > The commands should lead to a correct user experience, in particular > with an easy way to enable tab completion on popular > terminals/shells. Modern mercurial should have a command to setup > completion (something like https://pixi.sh/latest/#autocompletion). > > Using /usr/bin/python3 -m pip install (--user) or > --break-system-packages are really bad practice. > > Using hg-git or topics should not require writing by hands strange > lines in ~/.hgrc. It is too difficult for beginners (terminal editors > are hard for them) and for teaching it's sure that few students will > do it wrong and get a buggy behavior. Nowadays, I wonder if hg-git > and topics could not be automatically activated if they are installed > for the Python used by Mercurial? Is there a good reason not to do > that? It would be possible directly after `pipx inject mercurial > hg-evolve hg-git` to clone Mercurial repositories using topics and > Git repositories from Github. > > If it does not make sense to auto activate topics and hg-git, > Mercurial should have a simple interface (command line or maybe > something like what we get with `hg commit -i`) to modify its user > configuration. > > More generally, with Git, one can run `git config --global user.name > "Mona Lisa"`, which is convenient for beginners (much more than > editing a file). > > > 2. the difference between modern mercurial with topics and hg-git > with bookmarks is an issue. We should not need to use/teach bookmarks > to interact with a Git repository. Topics are much better. Most Git > branches on Github which are not called master or main should be > represented by topics (of course, there are exceptions which should > be handled). I know that Dan Villiom Podlaski Christiansen works on a > topic on this feature > (https://foss.heptapod.net/mercurial/hg-git/-/merge_requests/101), > which is planed for hg-git 2.0.0. However, I start to be less > confident that it will be one day usable. > > Moreover phases should be by default reasonable when working with Git > repos (at least commits pushed on main/master should be public). > > > Sorry to tell all these negative statements but I feel that without > changes and more focus on usability for beginners, I will have to > stop to communicate on Mercurial and teach Mercurial. If this is a > matter of founding, I may be able to help a bit and more generally we > should organize ourself to get enough money to get these > improvements. _______________________________________________ > Mercurial mailing list Mercurial@lists.mercurial-scm.org > https://lists.mercurial-scm.org/mailman/listinfo/mercurial I agree. A plan is needed. Mercurial is a great piece of software but it seems to have a few broken windows. Git has Linus and we have... nobody. Is there even a project lead? _______________________________________________ Mercurial mailing list Mercurial@lists.mercurial-scm.org https://lists.mercurial-scm.org/mailman/listinfo/mercurial
