On Nov 20, 2009, at 10:09 PM, Greg Ewing wrote: > Christopher Barker wrote: > >> I'm still not used to the fact that 6.4 MB is inconsequential! > > It's not inconsequential to some people -- not everyone > has a blazingly fast nearly-free internet connection.
True, though the target audience is much more likely to have a good internet connection, and when downloading it's compressed to about half that. (I pity the developer trying to use Cython on a machine where half a dozen MB is a consequential burden on their hard drive.) On Nov 20, 2009, at 10:18 PM, Greg Ewing wrote: > Robert Bradshaw wrote: >> It might be interesting if there was a way to have a partial >> history, so that one could easily make patches/pull/move forward, but >> of course not roll back to arbitrary points in time. I don't know if >> that's possible with hg. > > A user can get that effect themselves by initializing > a new hg repository in their source before they start > to modify it. Then it's easy to generate patches relative > to whatever they started with. > > I did that myself when I developed the yield-from > implementation for Python, and it worked very well. Yes, that works, but it changes a (usually insignificant) burden on all users' equipment to a (minor but annoying) burden on potential developers themselves. A key point here is that you started with the intent to work on Python. A typical workflow with an open source project is. 1) Use. Use a lot until it becomes essential. 2) Find a bug that I need to fix to keep using the software (fortunately, I rarely hit this point). Or maybe come up with a feature that I think would be really cool to have. 3) Hack. 4) Submit the fix upstream. People moving onto step (4) is what makes an open source project successful. Having to insert "figure what revision control is used, download the dev version, ..." before step (3) blocks the creative juices--at this point often I'm just looking for a workaround, and might work it into a real fix later, and don't want to be bothered with that even if eventual contribution is as the back of my head. Inserting that step after (3) involves figuring out what I changed and copying stuff over (where one half is missing the revision control, and the dev branch might have changed since). I have to admit that there are times I've not contributed stuff upstream just because I was too lazy to get the dev version and integrate my changes over, especially when doing so was completely orthogonal to my task at hand. One of the great things about the Sage project (which I think has helped greatly, and I try to emulate with Cython) is reducing the gap between "user" and "developer." Many contributors to Sage didn't start out intending to be contributors, but it was so easy that when they saw the need, with the proper encouragement, it just happened. As they got more comfortable with the code the contributions became more significant and more numerous. I think there's more "starter" projects in Sage than in Cython, but we're also in the very lucky position that almost all users of Cython are already Python developers. If people get to (3), it should be really easy to get to (4). Anyway, that's my long-winded defense of those 6.4 MB. A script to turn a simple source directory into a full-blown repository would nearly meet the above goals, and is probably not that hard. Anyone want to submit a patch? :-) > You could facilitate it by including a .hgignore file > in the source distribution excluding .pyc files, etc. > to save the user from having to create his own. .hgignore is itself under revision control. - Robert _______________________________________________ Cython-dev mailing list [email protected] http://codespeak.net/mailman/listinfo/cython-dev
