-
Notifications
You must be signed in to change notification settings - Fork 1
Modware Loader Development
-
Please inform author about your intent of development. Either email directly or preferably use the github issue tracker. If it's tied to any existing issue, please make sure to refer it.
-
It is primarily intended for authoring and developmental purpose. Skip this whole document if your sole purpose is to use the commands. Instead follow this document.
-
Any issue regarding installation/use of third party modules is beyond the scope of this document, please refer to their individual documentation for details. Consulting and/or searching stackoverflow and/or google is highly recommended.
A working knowledge with the following softwares and related workflows are vitally important.
- git: A basic understanding of branch, merge, pull, push and remote are necessary.
- Modern Perl based development: This refers to the principles and modules described in the modern perl book. Please try to understand the concept before proceeding any further.
-
Unit testing: Writing unit tests with perl module, particularly
Test::More. This is a simple tutorial to get started. -
Interacting with SQL database from Perl: Knowledge of perl
DBImodule. Read the 18 part DBI article here. - Basic knowledge of working with github, like tracking issues, managing pull requests and releases.
Modware-Loader development uses git for source code management. It roughly follows this git branching model. Even for core developers and maintainers we use github pull request for code contribution and review. These are roughly the steps we follow for development ...
- Clone the development branch of repository.
- Create you own branch from development. Use the following convention for branch name ...
- For adding new feature:
feature/<branch name> - For refactoring:
refactor/<branch name> - For fixing bugs:
bugs/<branch name> - For adding documentation:
documentation/<branch name>Use short but meaningful ``branch name. For example if you want to add a blast loader usefeature/blast-loader```. If its something not cover here use common sense.
- For adding new feature:
The purpose of this setup is different from a regular user oriented install.
We use cpanm for installing dependencies. Use your OS's package manager or perlbrew or plenv to install it.
- Go to your project folder.
- Run
cpanm -n .The-noption allows for faster install, however if you prefer run it without-n. - It is recommended to use project specific local library path for managing dependencies. Use
perlbrew,plenvorlocal::libfor that. For further information consult their documentation. -
cpanmwill not pull optional dependencies by default. In order to install optional dependencies just use
cpanm -n [module-name]
cpanm -n DBD::Oracle DBD::Pg (for example)In case the dependencies resides only on github but not on cpan, use the git syntax of cpanm for install.
- Install pmtools.
cpanm -n Devel::Loaded- Then run for any module you want to check
pmvers [Module-Name]
pmvers DBI
pmvers DBD::Oracle
pmvers Test::Chadopmtools is also full of goodies and utility commands, might come handy.
The standard practice is to have accompanying unit tests for any code addition or changes with any pull request. To write any unit test, first install Test::Chado module.
cpanm git://github.com/dictyBase/Test-Chado.gitAlways do a build and test before starting any development.
perl Build.PL
./Build testMake sure all test passes. If not, inform the author or apply a fix followed by a pull request.
To test a specific test file run
./Build test --test_files t/mytestfile.tOnce the test passes send a pull request and you're done.
Release management is done through Dist::Zilla. For details about Dist::Zilla and how it works go through the tutorials.
- Install
Dist::Zilla.
cpanm -n Dist::ZillaGet a coffee or something, should take a while.