In the previous post, I discussed about the similarity function that I plan to use for the process of de-duplication of incoming notes from hg commits. The last two weeks involved working on newer versions of the patch that I sent for it. One of the problems that I encountered was the exercise of using an external dependency called fuzzywuzzy. Majority of the open source software avoid importing third party modules, because of the fear that it might not be updated with changes in language or there might be syntax changes in further version updates, for eg. module X might not be compatible anymore as the software moves from Python 2.7 to Python 3.5. What they generally try is to develop the same tool using the standard library packages. This way they don’t need to worry about the maintenance. But due to some reason, if they require adding a third party package, they ensure to include proper testing measures to make sure any errors related to these packages are caught first hand.

Since fuzzywuzzy is an external package, one of the initial problems that someone might face while using it is an Import error. I know, we all have been there sometime or the other resolving this error. In its test suite, Mercurial contains an hghave.py file that contains specific functions for checking the import of the modules involved in the Mercurial codebase.

@check("fuzzywuzzy", "Fuzzy string matching library")
def has_fuzzywuzzy():
    try:
        import fuzzywuzzy
        fuzzywuzzy.__version__
        return True
    except ImportError:
        return False

While writing Perl tests, we simply use #require fuzzywuzzy and with this statement it executes the function from hghave. It is a really small thing to have but a really important measure to be taken when building good software.

Custom Sections


While discussing about the release notes extension, I also mentioned about the sections involved in a notes file. In general, a software requires sections like Bug Fixes, New Features etc., these are placed as default sections in the code. But it might be possible that a project team might require custom sections like File Additions or someone might want changes sectioned under month, then they can add sections like May 17, June 17 etc.. For this purpose we will use configurations. This configurations will be parsed by the extension and be available for use. Now, one approach is to add this config in the .hgrc file.

[releasenotes.section]
fileadd = File Additions
may2017 = May 17
june2017 = June 17

Mercurial consists of a function configitems() that allows us to easily parse the config by just passing the tag name. But there is a problem in using this method. The .hgrc file is user-limited and thus every member of the team will need to have the hgrc file configured. The other approach is to use our own file like .hgsections or .hgadmonitions. This way every user will have access to the configurations on cloning the repository.

That’s all for now. I gotta get back to the terminal :D!