PK t½B•åK_) _) - packaginator-latest/testing_instructions.html
How to customize the settings to suit your needs. Do this in local_settings so patches and upstream pulls don’t cause havoc to your installation
Used to control the URL for the admin in production.
Used to create the name of the site.
Used to determine how packages have extended data sets. See package_extenders
In the case of Django Packages, autocomplete searches for something like ‘forms’ was problematic because so many packages start with ‘django’. The same will hold for searches in Python Packages and Pyramid Packages. This prefix is accommodated in searches to prevent this sort of problem.
example:
PACKAGINATOR_SEARCH_PREFIX = 'pyramid'
Used in the Package add/edit form in both the admin and the UI, these are assigned to model form help text arguments. Takes a dict of the following items:
Example (also the default):
PACKAGINATOR_HELP_TEXT = {
"REPO_URL" : "Enter your project repo hosting URL here.<br />Example: https://bitbucket.org/ubernostrum/django-registration",
"PYPI_URL" : "<strong>Leave this blank if this package does not have a PyPI release.</strong><br />What PyPI uses to index your package. <br />Example: django-registration"
}
The launchpad Python client tool requires an unbelievable amount of requirements to handle a simple JSON ReST based webservice. These requirements can be tricky to install. Therefore, OpenComparison out of the box does not support Launchpad.
Warning
Launchpad hasn’t been tested or maintained in a while. This probably won’t work at this time.
If you have problems, please refer to troubleshooting.
If you want your instance of OpenComparison to support Launchpad, set this setting to true in local_settings.py:
LAUNCHPAD_ACTIVE = True
Used to point LAUNCHPAD commands against the appropriate cache. Important in real hosting machines.
Example:
LAUNCHPAD_CACHE_DIR = "/tmp/lp-cache"
OpenComparison provides several ways to control who can make what changes to things like packages, features, and grids. By default, a OpenComparison project is open to contributions from any registered user. If a given project would like more control over this, there are two settings that can be used.
RESTRICT_PACKAGE_EDITORS RESTRICT_GRID_EDITORS
If these are not set, the assumption is that you do not want to restrict editing.
If set to True, a user must have permission to add or edit the given object. These permissions are set in the Django admin, and can be applied per user, or per group.
By default registered users can do the following:
Packages
Grids
In the default condition, only super users or those with permission can delete.
A context processor will add the user profile to every template context, the profile model also handles checking for permissions:
{% if profile.can_edit_package %}
<edit package UI here>
{% endif %}
The follow properties can be used in templates:
OpenComparison solves the problem in the programming community of being able to easily identify good apps, frameworks, and packages. Ever want to know which is the most popular or well supported Python httplib replacement, web framework, or api tool? OpenComparison solves that problem for you!
It does this by storing information on packages fetched from public APIs provided by PyPI, Github, BitBucket, Launchpad, and SourceForge, and then provides extremely useful comparison tools for them.
Contents:
For Django Dash 2010, @pydanny and @audreyr were scared of rabbits.
Since then the project has had many contributors.
This is the API documentation for OpenComparison. It is designed to be language and tool agnostic.
The current API is limited to read-only GET requests. Other HTTP methods will fail. Only JSON is provided
URI | Resource | Methods |
---|---|---|
<http-my-domain.com>/api/v1/ | Root | GET |
URI | Resource | Methods |
---|---|---|
/category/ | Category list | GET |
/category/{slug}/ | Category | GET |
/grid/ | Grid list | GET |
/grid/{slug}/ | Grid | GET |
/grid/{slug}`/packages`_/ | Grid Packages list | GET |
/grid-of-the-week/ | Featured Grid list | GET |
/grid-of-the-week/{slug}/ | Featured Grid | GET |
/package/ | Package list | GET |
/package/{slug}/ | Package | GET |
/package-of-the-week/ | Featured Package list | GET |
/package-of-the-week/{slug}/ | Featured Package | GET |
Representation:
{
created: "Sat, 14 Aug 2010 19:47:52 -0400"
description: "Small components used to build projects. An app is anything that is installed by placing in settings.INSTALLED_APPS."
modified: "Sat, 28 Aug 2010 11:20:36 -0400"
resource_uri: "/api/v1/category/apps/"
slug: "apps"
title: "App"
title_plural: "Apps"
}
Representation:
{
absolute_url: "/grids/g/cms/"
created: "Sat, 14 Aug 2010 20:12:46 -0400"
description: "This page lists a few well-known reusable Content Management System applications for Django and tries to gather a comparison of essential features in those applications."
is_locked: false
modified: "Sat, 11 Sep 2010 14:57:16 -0400"
packages: [
"/api/v1/package/django-cms/"
"/api/v1/package/django-page-cms/"
"/api/v1/package/django-lfc/"
"/api/v1/package/merengue/"
"/api/v1/package/mezzanine/"
"/api/v1/package/philo/"
"/api/v1/package/pylucid/"
"/api/v1/package/django-gitcms/"
"/api/v1/package/django-simplepages/"
"/api/v1/package/djpcms/"
"/api/v1/package/feincms/"
]
resource_uri: "/api/v1/grid/cms/"
slug: "cms"
title: "CMS"
}
Representation:
{
absolute_url: "/grids/g/cms/"
created: "Sun, 15 Aug 2010 01:36:59 -0400"
end_date: "22 Aug 2010"
modified: "Sun, 15 Aug 2010 01:36:59 -0400"
resource_uri: "/api/v1/grid-of-the-week/cms/"
start_date: "15 Aug 2010"
}
Representation:
{
absolute_url: "/packages/p/pinax/"
category: "/api/v1/category/frameworks/"
created: "Mon, 16 Aug 2010 23:25:16 -0400"
grids: [
"/api/v1/grid/profiles/"
"/api/v1/grid/social/"
"/api/v1/grid/this-site/"
]
modified: "Sun, 12 Sep 2010 17:02:10 -0400"
participants: "pinax,brosner,jtauber,jezdez,ericflo,gregnewman,pydanny,edcrypt,paltman,dougn,alex,vgarvardt,alibrahim,lukeman,shentonfreude,jpic,httpdss,mikl,empty,brutasse,kwadrat,sunoano,robertrv,stephrdev,justinlilly,deepthawtz,skyl,googletorp,maicki,havan,zerok,hellp,asenchi,haplo,chimpymike,beshrkayali,zain,bartTC,ntoll,fernandoacorreia,oppianmatt,dartdog,gklein,acdha,ariddell,vikingosegundo,thraxil,rhouse2"
pypi_downloads: 0
pypi_url: "http://pypi.python.org/pypi/Pinax"
pypi_version: "0.9a1"
repo: "/api/v1/repo/1/"
repo_commits: 0
repo_description: "a Django-based platform for rapidly developing websites"
repo_forks: 184
repo_url: "http://github.com/pinax/pinax"
repo_watchers: 913
resource_uri: "/api/v1/package/pinax/"
slug: "pinax"
title: "Pinax"
}
Representation:
{
absolute_url: "/packages/p/django-uni-form/"
created: "Sun, 15 Aug 2010 01:36:38 -0400"
end_date: "15 Aug 2010"
modified: "Mon, 16 Aug 2010 23:54:36 -0400"
resource_uri: "/api/v1/package-of-the-week/django-uni-form/"
start_date: "14 Aug 2010"
}
Before you do anything else, login/signup on GitHub and fork OpenComparison from the GitHub project.
If you have git-scm installed, you now clone your git repo using the following command-line argument where <my-github-name> is your account name on GitHub:
git clone git@github.com:<my-github-name>/opencomparison.git
Follow our detailed installation instructions. Please record any difficulties you have and share them with the OpenComparison community via our issue tracker.
The list of outstanding OpenComparison feature requests and bugs can be found on our on our GitHub issue tracker. Pick an unassigned issue that you think you can accomplish, add a comment that you are attempting to do it, and shortly your own personal label matching your GitHub ID will be assigned to that issue.
Feel free to propose issues that aren’t described!
While it’s handy to provide useful code snippets in an issue, it is better for you as a developer to submit pull requests. By submitting pull request your contribution to OpenComparison will be recorded by Github.
In git it is best to isolate each topic or feature into a “topic branch”. While individual commits allow you control over how small individual changes are made to the code, branches are a great way to group a set of commits all related to one feature together, or to isolate different efforts when you might be working on multiple topics at the same time.
While it takes some experience to get the right feel about how to break up commits, a topic branch should be limited in scope to a single issue as submitted to an issue tracker.
Also since GitHub pegs and syncs a pull request to a specific branch, it is the ONLY way that you can submit more than one fix at a time. If you submit a pull from your master branch, you can’t make any more commits to your master without those getting added to the pull.
To create a topic branch, its easiest to use the convenient -b argument to git checkout:
git checkout -b fix-broken-thing
Switched to a new branch 'fix-broken-thing'
You should use a verbose enough name for your branch so it is clear what it is about. Now you can commit your changes and regularly merge in the upstream master as described below.
When you are ready to generate a pull request, either for preliminary review, or for consideration of merging into the project you must first push your local topic branch back up to GitHub:
git push origin fix-broken-thing
Now when you go to your fork on GitHub, you will see this branch listed under the “Source” tab where it says “Switch Branches”. Go ahead and select your topic branch from this list, and then click the “Pull request” button.
Here you can add a comment about your branch. If this in response to a submitted issue, it is good to put a link to that issue in this initial comment. The repo managers will be notified of your pull request and it will be reviewed (see below for best practices). Note that you can continue to add commits to your topic branch (and push them up to GitHub) either if you see something that needs changing, or in response to a reviewer’s comments. If a reviewer asks for changes, you do not need to close the pull and reissue it after making changes. Just make the changes locally, push them to GitHub, then add a comment to the discussion section of the pull request.
OpenComparison is advancing quickly. It is therefore critical that you pull upstream changes from master into your fork on a regular basis. Nothing is worse than putting in a days of hard work into a pull request only to have it rejected because it has diverged too far from master.
To pull in upstream changes:
git remote add upstream https://github.com/opencomparison/opencomparison.git
git fetch upstream
Check the log to be sure that you actually want the changes, before merging:
git log upstream/master
Then merge the changes that you fetched:
git merge upstream/master
For more info, see http://help.github.com/fork-a-repo/
We want your submission. But we also want to provide a stable experience for our users and the community. Follow these rules and you should succeed without a problem!
Before you submit a pull request, please run the entire OpenComparison test suite via:
python manage.py test --settings=settings.test
The first thing the core committers will do is run this command. Any pull request that fails this test suite will be rejected.
We’ve learned the hard way that code without tests is undependable. If your pull request reduces our test coverage because it lacks tests then it will be rejected.
For now, we use the Django Test framework (based on unittest).
Also, keep your tests as simple as possible. Complex tests end up requiring their own tests. We would rather see duplicated assertions across test methods then cunning utility methods that magically determine which assertions are needed at a particular stage. Remember: Explicit is better than implicit.
If you change two lines of code and correct 200 lines of whitespace issues in a file the diff on that pull request is functionally unreadable and will be rejected. Whitespace cleanups need to be in their own pull request.
OpenComparison pull requests should be as small/atomic as possible. Large, wide-sweeping changes in a pull request will be rejected, with comments to isolate the specific code in your pull request. Some examples:
Memorize the Zen of Python:
>>> python -c 'import this'
Please keep your code as clean and straightforward as possible. When we see more than one or two functions/methods starting with _my_special_function or things like __builtins__.object = str we start to get worried. Rather than try and figure out your brilliant work we’ll just reject it and send along a request for simplification.
Furthermore, the pixel shortage is over. We want to see:
Any css/layout changes need to be tested in Chrome, Safari, Firefox, IE8, and IE9 across Mac, Linux, and Windows. If it fails on any of those browsers your pull request will be rejected with a note explaining which browsers are not working.
First we pull the code into a local branch:
git remote add <submitter-github-name> git@github.com:<submitter-github-name>/opencomparison.git
git fetch <submitter-github-name>
git checkout -b <branch-name> <submitter-github-name>/<branch-name>
Then we run the tests:
python manage.py test
We finish with a non-fastforward merge (to preserve the branch history) and push to GitHub:
git checkout master
git merge --no-ff <branch-name>
git push upstream master