(→Getting the sources: add link to new git tutorial)
(→Getting the code: recommend rasterific)
|(8 intermediate revisions by 2 users not shown)|
Latest revision as of 02:17, 19 April 2015
 1 Getting involved
There are two major ways to get involved in the diagrams community and find out what is going on:
- The IRC channel (
#diagramson freenode.org) is fairly active and a good place to interact with other diagrams users and developers. (Be patient: sometimes no one is watching the channel, but if you say something or ask a question, you can be sure that someone will eventually see it and respond.)
- The mailing list is the place to stay up-to-date with announcements, and also a good place to ask questions, especially longer or more involved ones.
 2 Getting the sources
All the core diagrams code can be found in the diagrams organization on github.
If you don't already know how to work with repositories hosted on github, take a look at some introductory material like this book about git and this github tutorial and this interactive tutorial-game-thingy. The hub utility is an optional but recommended tool for simplifying common tasks involving github. The mr utility is an optional tool for simplifying tasks involving multiple git repositories.
 3 Choosing a project
If you would like to begin contributing to the diagrams project but are not sure where to start, here are a few resources that may be helpful:
- The Trello board for diagrams has lots of ideas for projects, todos, and gives a snapshot of what various people are working on.
- Take a look at the issue trackers for repositories in the diagrams organization on github, especially those for the diagrams-core, diagrams-lib, diagrams-contrib, and diagrams-doc repositories.
- See the projects page for a list of ongoing bigger projects to get involved with, or new projects to start.
- Don't hesitate to ask for ideas on the mailing list or IRC channel.
 4 Best practices
 4.1 Getting the code
as well as a backend, such as:
If you do not plan to make any modifications to the code in a certain repo, you may clone it directly instead of first forking on github and then cloning from your fork, for example
or, using hub, simply
hub clone diagrams/diagrams-core
(In fact, hub makes it easy to later convert a direct clone into your own fork if you wish, via the
hub fork command; see the hub documentation for more information.)
Or save this file as ~/.mrconfig, and run `mr update` to checkout all of the recommended repositories.
 4.2 Building
It's recommended to use some sort of sandboxing tool while working on diagrams. Because diagrams consists of several separate packages, using cabal-dev can be something of a pain. Instead, we recommend using hsenv. cabal-sandbox also works well, except for diagrams-doc.
In any case, there is an important trick for building multiple local packages at once that you should know, which works with cabal as well as cabal-dev. Instead of installing each package one at a time, simply go up to the parent directory and issue a command such as
cabal install monoid-extras/ dual-tree/ diagrams-core/ diagrams-lib/ diagrams-cairo/ diagrams-contrib/
The trailing slashes tell cabal to install packages from local directories, rather than trying to download packages from Hackage. In addition, it doesn't even matter in what order you list the directories; cabal will figure out the correct order based on dependencies.
 4.2.1 Cabal Sandbox
Most likely, you will want to use a single sandbox for all your diagrams work, so you don't need to rebuild packages when you switch from one package to another. The simplest way to get started is to make the sandbox in the parent directory, and call all cabal commands from there:
cd diagrams cabal sandbox init cabal install core/ lib/ contrib/ svg/
At some point you may want to use other cabal commands (eg, build, haddock), or just want the convenience of calling cabal from inside a particular package directory. This command points cabal at the shared sandbox:
cd diagrams/core cabal sandbox init --sandbox=../.cabal-sandbox
After doing this, any future cabal commands in diagrams/core will use the shared sandbox.
 4.3 Making changes
Now that you have your cloned/forked repositories and know how to build them, go ahead and make some edits. You can see what changes you've made using the
git diff command, stage certain changes with
git add (try the
-p flag!), and create a commit from staged changes with
For coding style, see Johan Tibell's Haskell style guide.
You are also encouraged to update the diagrams user manual in parallel with any changes you make; see the diagrams-doc repository.
 4.4 Submitting a pull request
Once you have a set of commits you are happy with, push them to your forked repository on github and open a pull request. At this point your code will be reviewed by someone with push access to the repository. They may very well leave some comments; feel free to respond with comments of your own.
If any errors are pointed out, changes requested, etc., simply make some new commits and push them to your forked repo. There is no need to create another pull request; any newly pushed commits will be automatically added to the existing pull request.
 4.5 Pull requests and topic branches
The important thing to realize about pull requests is that they do not correspond to a particular set of commits, but to a branch. In particular, you add new commits to a pull request simply by pushing to the branch which the pull request is from. This has some interesting implications:
- If you are going to be working on multiple features/bug fixes at once---or even if you just want to be able to get started on a new feature while your previous one is still undergoing review---it is best to create a "topic branch" for each feature, rather than making all your changes on your "master" branch. You can create a new branch called
git branch foo; see all branches with
git branch; and switch between branches using
- Once your pull request is merged, you can delete the branch, using
git branch -d foofor the branch in your local repo, and something like
git push origin --delete foofor a remote repo named
- Another interesting point is that there's not necessarily any reason to wait until you are "done" to open a pull request. Just make sure you state that the feature is "in progess", and then you can get useful early feedback as you continue to work on the feature and push more commits. Of course, branches/pull requests also make for a nice way to work on a new feature collaboratively.
 4.6 Keeping up to date
It can be a bit tedious to make sure you have all the latest changes to diagrams across a dozen git repos. The mr tool automates this process. If you did not use mr to check out the repositories, first inform mr of the repos as follows:
- checkout all the repositories with a common parent directory, as above
- in each checkout, run
To pull changes, run
mr update from the common parent directory.