Uh oh!
There was an error while loading.Please reload this page.
- Notifications
You must be signed in to change notification settings - Fork7.9k
Updated docs to refer to git#3
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to ourterms of service andprivacy statement. We’ll occasionally send you account related emails.
Already on GitHub?Sign in to your account
Uh oh!
There was an error while loading.Please reload this page.
Changes fromall commits
b940899
94cdae9
071b769
7e55c11
File filter
Filter by extension
Conversations
Uh oh!
There was an error while loading.Please reload this page.
Jump to
Uh oh!
There was an error while loading.Please reload this page.
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -36,12 +36,12 @@ build_osx105: | ||
jdh_doc_snapshot: | ||
git checkout;\ | ||
python setup.py install --prefix=~/dev;\ | ||
cd doc;\ | ||
rm -rf build;\ | ||
python make.py clean;\ | ||
git checkout;\ | ||
python make.py html latex sf sfpdf; | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others.Learn more. Are we going to have to make changes to the make doc commands such as "sf" and "sfpdf"? There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others.Learn more. Yes. But they don't have to be addressed in this round of changes, since for the time being the webpage is still being hosted at sourceforge. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others.Learn more. I'm not sure that "git checkout" makes any sense here; it will just print some message. "svn up" is the rough equivalent of "git pull git://github.com/matplotlib/matplotlib.git master" at least if you have the master branch checked out. | ||
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -4,31 +4,42 @@ | ||
Coding guide | ||
************ | ||
.._building_source: | ||
Building from source code | ||
------------------------- | ||
Developers should look through the | ||
:ref:`development quickstart <development-quickstart>` | ||
documentation. There you will find information on building NIPY, the | ||
required software packages and our developer guidelines. | ||
If you are primarily interested in using NIPY, download the source | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others.Learn more. NIPY is a neuroimaging package. How did it get here? | ||
tarball and follow these instructions for building. The installation | ||
process is similar to other Python packages so it will be familiar if | ||
you have Python experience. | ||
Unpack the source tarball and change into the source directory. Once in the | ||
source directory, you can build the neuroimaging package using:: | ||
python setup.py build | ||
To install, simply do:: | ||
sudo python setup.py install | ||
.. note:: | ||
As with any Python_ installation, this will install the modules | ||
in your system Python_ *site-packages* directory (which is why you | ||
need *sudo*). Many of us prefer to install development packages in a | ||
local directory so as to leave the system python alone. This is | ||
mearly a preference, nothing will go wrong if you install using the | ||
*sudo* method. To install in a local directory, use the **--prefix** | ||
option. For example, if you created a ``local`` directory in your | ||
home directory, you would install nipy like this:: | ||
python setup.py install --prefix=$HOME/local | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others.Learn more. Even easier to just do "--user", although that might just be for setupegg.py... There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others.Learn more. That was added, when, in python-2.6? We should discuss which python versions will be supported by future versions of matplotlib, but on the development mailing list There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others.Learn more. I believe it was added in python 2.5, but I have nothing definitive on that. In any case, I believe we are still supposed to support python 2.4 | ||
Committing changes | ||
@@ -61,228 +72,9 @@ in mind. | ||
distribution of the mpl build. | ||
* Keep the maintenance branch (0.91) the latest release branch (eg | ||
0.98.4) and trunk in sync where it makes sense. | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others.Learn more. I think this needs to be elaborated upon. It is possible to arrange merging in many ways, but one simple way would be to always merge feature branches to the oldest relevant branch first, then that branch into any newer branches. I.e. if we have a "v1.0.x" maintenance branch and a "master" development branch, and there is a bugfix that we want to apply to v1.0.x, we would merge it first into v1.0.x and then v1.0.x into master. I think this corresponds to the old svnmerge.py based workflow and to the recommendation athttp://www.kernel.org/pub/software/scm/git/docs/gitworkflows.html. It is also possible to merge bugfix branches separately into maintenance and development branches as inhttp://nvie.com/posts/a-successful-git-branching-model/ but I think that requires more care in tracking that the fixes really get applied on every branch they need to. | ||
.. _style-guide: | ||
@@ -353,7 +145,7 @@ use `reindent.py | ||
<http://svn.python.org/projects/doctools/trunk/utils/reindent.py>`_ as | ||
a command-line script. Unless you are sure your editor always | ||
does the right thing, please use reindent.py before checking changes into | ||
git. | ||
Keep docstrings_ uniformly indented as in the example below, with | ||
nothing to the left of the triple quotes. The | ||
@@ -367,7 +159,7 @@ It may be preferable to use a temporary variable to replace a single | ||
long line with two shorter and more readable lines. | ||
Please do not commit lines with trailing white space, as it causes | ||
noise ingit diffs. Tell your editor to strip whitespace from line | ||
ends when saving a file. If you are an emacs user, the following in | ||
your ``.emacs`` will cause emacs to strip trailing white space upon | ||
saving for python, C and C++: | ||
@@ -582,22 +374,22 @@ generated when the website it built to show up both in the `examples | ||
website. Many people find these examples from the website, and do not | ||
have ready access to the file:`examples` directory in which they | ||
reside. Thus any example data that is required for the example should | ||
be provided through the sample_datagit directory, which can then be | ||
accessed using :func:`matplotlib.cbook.get_sample_data`. First get a | ||
copy of the repository andgit add your data:: | ||
git clone https://github.com/matplotlib/sample_data.git | ||
cp ~/path/to/mydata.dat sample_data/ | ||
cd sample_data | ||
git add mydata.dat | ||
git commit -m 'added my data' | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others.Learn more. "svn commit" pushes the changes into the centralized repository; "git commit" only commits them locally. The instructions should include a "git push" command, or instructions to make a pull request (depending on our policy for the sample_data repository). There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others.Learn more. Also, it seems get_sample_data in cbook.py has not been updated to use the git repository. I can do that in another pull request. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others.Learn more. Jouni, save your effort. I already took care of it in pull request#2 | ||
and then in your example code you can load it into a file handle with:: | ||
import matplotlib.cbook as cbook | ||
fh = cbook.get_sample_data('mydata.dat') | ||
The file will be fetched from thegit repo using urllib and updated | ||
when the revision number changes. | ||
Uh oh!
There was an error while loading.Please reload this page.