search

ezag / pyeuclid

2D and 3D maths module for Python
97 stars 41 forks source link

integrate with travis ci #7

Closed brad closed 7 years ago

brad commented 10 years ago

Along with my previous pull request to update the docs and Makefile (#6), this request integrates with travis-ci.org to provide continuous integration. It verifies that the pyeuclid docs and tests successfully build and that pyeuclid installs properly an pythons 2.6, .27, 3.2, 3.3 and pypy.

bootchk commented 10 years ago

I'm an interested bystander (I forked pyeuclid to geometryFramed.) I haven't read Travis docs. My questions may not be appropriate.

Is the makefile depending on tools from python2.4 and 2.5 in certain hard locations compatible with travis?

How often will travis build? Is it integrated with Github enough to build only when there is a new commit?

How does that help developers (working on their own branch) do continuous integration? Does a developer sic Travis on their own branch on Github?

brad commented 10 years ago

@bootchk Check out my master branch as an example. I simply went to http://travis-ci.org and flipped a switch and now it is integrated with my Github repository. Every time a commit is made in any branch which contains the .travis.yml file, travis will pull it in and run the doc tests. It will do the same for pull requests and indicate on github if the pull request passes the tests.

In my master branch I have also added http://coveralls.io integration so I can see what percentage of the code is covered by tests. I would be happy to make a pull request for that as well once this request is merged in.

This pull request depends on my other request (#6) which drops support for python 2.4/2.5. The makefile depends on the docutils package which gets install via pip on the travis vm. Take a look at .travis.yml to get a feel for how it works.

To answer your last question, it helps developers on their own branch because you can do exactly what I did and enable your own repo on travis-ci so it can run tests for your commits. Hope that helps to answer your questions.

bootchk commented 10 years ago

Thanks, that is very informative.

But shouldn't a developer make (which runs the tests) before doing a commit. So travis provides assurances to other developers that a developer's commit will pass tests on all versions of Python. That seems worthy.

brad commented 10 years ago

You're right of course. Ideally a developer should make on all supported versions of python before commiting, but I kind of like letting travis take care of that for me. Then if I end up with too many commits in my branch, sometimes I'll rebase to clean it up a bit. I also love the integration with coveralls.io. Not only does it give you readable coverage reports, but it keeps a history of it all too.

bootchk commented 10 years ago

(This might not be the appropriate place for this question...)

Why did you fork, or why are you bothering to submit pull requests? In other words, I'm wondering about the social aspects and the problem with having too many forks. How are others to choose between your repository and this one?

I would guess that by submitting pull requests here, you are trying to keep the repositories equal. If your pull requests here are not being honored (apparently), then your fork becomes divergent? Then are you committing yourself to capture any fixes made here and in the ancestor google project (assuming some people make fixes here and there) so that your divergent fork becomes the defacto best one, since it is maintained?

Note I'm not suggesting you do anything particular or that you have done anything wrong. I'm just wondering how you see the situation.

(As someone who has also forked and diverged this project. As I recall, I informally suggested changes to the project (frame safety and separating vectors from points, but it was not well received. But I needed it, so I forked. I wouldn't claim my fork is better, just different.)

brad commented 10 years ago

Whenever I contribute to an open source project I try and find the fork with the most current support and submit pull requests to that fork. Usually I'm just trying to help out with the project without committing to providing full-time support. I very much dislike using my own fork and merging in changes from the master fork. I just want to get my feature in there and then count on the project maintainer to continue support. Adding Travis integration is, in my mind, like oiling the gears of a machine, resulting in a better library for everyone to use.

brad commented 7 years ago

@ezag Thanks for the merges. Better late than never :wink: