Hacking on Hy¶
Join our Hyve!¶
Please come hack on Hy!
Please come hang out with us on
Please talk about it on Twitter with the
Please blog about it!
Please don’t spraypaint it on your neighbor’s fence (without asking nicely)!
Create a virtual environment:
$ virtualenv venv
and activate it:
$ . venv/bin/activate
or use virtualenvwrapper to create and manage your virtual environment:
$ mkvirtualenv hy $ workon hy
Get the source code:
$ git clone https://github.com/hylang/hy.git
or use your fork:
$ git clone firstname.lastname@example.org:<YOUR_USERNAME>/hy.git
Install for hacking:
$ cd hy/ $ pip install -e .
Install other develop-y requirements:
$ pip install -r requirements-dev.txt
Do awesome things; make someone shriek in delight/disgust at what you have wrought.
Tests are located in
tests/. We use nose.
To run the tests:
Write tests—tests are good!
Also, it is good to run the tests for all the platforms supported and for PEP 8 compliant code. You can do so by running tox:
Documentation is located in
docs/. We use Sphinx.
To build the docs in HTML:
$ cd docs $ make html
Write docs—docs are good! Even this doc!
Contributions are welcome & greatly appreciated, every little bit helps in making Hy more awesome.
Pull requests are great! We love them; here is a quick guide:
Fork the repo and create a topic branch for a feature/fix. Avoid making changes directly on the master branch. If you would like to contribute but don’t know how to begin, the good-first-bug label of the issue tracker is the place to go. (If you’re new to Git: Start Here)
Before contributing make sure you check the docs. There are two versions of docs available:
All incoming features should be accompanied with tests.
If you are contributing a major change to the Hy language (e.g. changing the behavior of or removing functions or macros), or you’re unsure of the proposed change, please open an issue in the issue tracker before submitting the PR. This will allow others to give feedback on your idea, and it will avoid constant changes or wasted work. For other PRs (such as documentation fixes or code cleanup), you can directly open the PR without first opening a corresponding issue.
Before you submit a PR, please run the tests and check your code against the style guide. You can do both of these things at once:
$ make d
Make commits into logical units, so that it is easier to track & navigate later. Before submitting a PR, try squashing the commits into changesets that are easy to come back to later. Also, make sure you don’t leave spurious whitespace in the changesets; this avoids creation of whitespace fix commits later.
As far as commit messages go, try to adhere to the following:
- Try sticking to the 50 character limit for the first line of Git commit messages.
- For more detail/explanations, follow this up with a blank line and continue describing the commit in detail.
Unless your change is very small, like a documentation wording improvement, add an item describing it to the NEWS file.
Finally, add yourself to the AUTHORS file (as a separate commit): you deserve it :)
All incoming changes need to be acked by 2 different members of Hylang’s core team. Additional review is clearly welcome, but we need a minimum of 2 signoffs for any change.
If a core member is sending in a PR, please find 2 core members that doesn’t include the PR submitter. The idea here is that one can work with the PR author, and a second acks the entire change set.
For documentation & other trivial changes, we’re good to merge after one ACK. We’ve got low coverage, so it’d be great to keep that barrier low.
Contributor Code of Conduct¶
As contributors and maintainers of this project, we pledge to respect all people who contribute through reporting issues, posting feature requests, updating documentation, submitting pull requests or patches, and other activities.
We are committed to making participation in this project a harassment-free experience for everyone, regardless of level of experience, gender, gender identity and expression, sexual orientation, disability, personal appearance, body size, race, ethnicity, age, or religion.
Examples of unacceptable behavior by participants include the use of sexual language or imagery, derogatory comments or personal attacks, trolling, public or private harassment, insults, or other unprofessional conduct.
Project maintainers have the right and responsibility to remove, edit, or reject comments, commits, code, wiki edits, issues, and other contributions that are not aligned to this Code of Conduct. Project maintainers who do not follow the Code of Conduct may be removed from the project team.
This code of conduct applies both within project spaces and in public spaces when an individual is representing the project or its community.
Instances of abusive, harassing, or otherwise unacceptable behavior may be reported by opening an issue or contacting one or more of the project maintainers.
The core development team of Hy consists of following developers: