Apologies for the ridiculously long delay.
I may not be able to devote the same amount of time as before, but I will certainly move to close bugs as soon as I can, and get to feature requests/patches as well.
My being gone for so long has made it clear that I need some kind of mechanism for allowing members of the community to work on drpy. Whether we are talking about completely giving the project over to a debian-ish contract, or just guidelines for bugfixes, I am not sure.
I am more than open to suggestions on this.
(Well, sort of. I am actually heading back to see my family for the holidays briefly, and will be "Back back" next monday.)
Wow! I had almost given up. I really hope you get things going again. Hopefully it won't be too hard to figure out how you can get others to contribute. If I could I certainly would.
I would be also interested.
What I have in mind.
As Dan, I also think, the core should be lean =>
so get rid of seldom used functions (maybe we can vote)
out of the core and make a plugin.
The source code could be checked again (for
The preferences dialog, I imagine, could look to overloaded
for new users.
If a program runs, I would like to have the possibility
to have the output pane not at the bottom, but at the
right side (as in scite). Also a white background
with colored output (for different messages) and a hotkey
like F4 for jumping to a buggy line, if a syntax error occurs.
(Maybe I have overseen something, i.e. some of this
things are implemented yet)
It seems to me that unless the source code is put into CVS and developers are able to work on it the project is effectively dead.
If the project is to live up to its billing as being suitable for education it needs to work right out-of-the-box. There are too many unresolved bugs and poorly designed features that trap new users. These are generally easy to solve and I have already submitted patches for some of them. For example the Prompt window locks up on Linux for want of a wx.Yield(true) statement. Several of the Preferences default to the wrong values (for example '~' is generally not recognised as the user's home directory on Windows). Experienced developers may not even realise that these problems exist unless they test DrPython as a new user without any previous Preferences.
This project represents an enormous amount of work. It would be a great pity if it were to go into decline for lack of an open development process that would enable others to contribute.
Christopher - I took at look and I see files in CVS for this project. However, I also notice that they're all 9 months old, or older. So it appears that the source code for the latest releases hasn't been put into CVS. So that's a problem for anyone who wants to work on the code. OTOH, you can just download the latest source from the files repository, work on it, and post updates as attachments. Naturally, this would get tiresome very quickly, though it would work as a stopgap measure.
If the lead developer has lost interest in the project, and doesn't want to continue, nor want to relinquish control by allowing other developers to upload code to CVS, we can at least thank the spirit of open-source. We can grab the latest snapshot, start a new sourceforge project, and press on.
An alternative approach seems to have been adopted by limodou, one of the listest developers. He has produced a new editor, NewEdit, that bears a great deal of resemblance to DrPython. We're welcome to work with him, I suppose (though I'd prefer to see his project on sourceforge).
Let's see what our drpython man has to say before deciding what the next step should be. I don't want to see this project slip away either!
As you said in response to a patch that I sent in it is difficult to deal with diff files - particulary on Windows. It is also difficult to keep patches separate for common files such as drpython.py.
As an interim solution before the CVS access is sorted out it might be possible to use Bazaar-NG.
This can be found at http://bazaar.canonical.com.
I tries setting up CVS on my Linux machine and found it very difficult to use. The commands have many options and the features are not well documented even in published books.
Subversion is much better but still not very easy to use.
Bazaar-NG (or Bzr for short) is a simple version control system that does not require a special repository since all the work is done in the client. The repository may either be a local directory or a remote website accessed by http. Because it is written in Python it can run on Windows as well as Linux. I have not yet tried it out but is looks very promising.
Christopher, did you see the Subversion book on the subversion website, at http://svnbook.org/ ?
I've deployed subversion on my own webserver and I didn't find it all that hard to set up. If we don't hear back from the drypython lead developer, I could offer to host the latest drpython code on an interim basis. this would allow us to incorporate all of the latest patches so that it's possible for a new user to get tip code.
I have now taken a look at Bazaar-NG and it seems to be too much a work-in-progress for immediate use.
I set-up CVS on my Linux machine and entered a project into it. It then told me that I could not alter it because the revision was "sticky". I could not find this term in the book I was using or in the extensive help for the Cervista GUI frontend. Also it srewed-up the graphics images by treating them as text files and changing any line terminators it found in the binary.
I do think that Subversion is a great deal better although my attempts to set-up a WebDAV interface were not successful. The most recent problem I had was to copy the trunk into an existing tag in order to make a correction. Somehow I managed to create the new tag as a subdirectory of the first tag. Perhaps I should have done the update a different way. The book I am using is "Pragmatic Version Control" which I prefer to the official one published by O'Reilly.
If the DrPython project really has been abandoned then there is a procedure at SourceForge for taking it over but this would take several weeks to complete. It is a great pity that none of the other developers were given the ability to keep the project ticking over. In the meantime I think we should take up your offer so that essential maintenance can be done.
I have looked at serveral editors/IDEs, such as Boa Constructor, SPE (Stani's Python Editor), Active Grid (which comes with wxPython), Python Card (recommended in the recently published book "Beginning Python", Wrox) but I still find DrPython the most appealing. I tried Eric3 which was distributed with a recent edition of "Linux Format". It has three dependencies but only two of them were supplied and the third had to be recompiled to include a nonstandard feature. The screenshot in the magazine showed two rows of about 40 icons each which I think is an absurd design. I had difficulty accessing the New Edit website. When I eventually managed to download a screenshot it showed a lot of small windows which did not seem to me to be practical.
At present I am working on a separate project to provide some project management facilities that DrPython lacks. When the ideas are worked out it might be possible to integrate them into DrPython in some way.
I'm not a fan of Eric3 either for the same reason as you - the interface is much too cluttered for my liking. In addition I find it crashes frequently.
I didn't have a lot of problems installing subversion - YMMV - and there is a good on-line book available for it.
let's see again after xmas where this project lies. I'm moving house, and working on a web app, so my time is a bit limited at the moment!
>If the DrPython project really has been abandoned...
I also don't know.
Did you contact Dan already per email?
If not, I will do.
I would be interested, what he thinks.
Again, I have gone missing for a long period of time. My new job, coupled with a penchant for getting myself into time consuming possibly age appropriate oddness outside of work, have not left me with very much time at all to spend "free hacking". I am however very excited to hear that there is still interest in continuing to hack on drpython. So:
Step 1 will involve my putting the current code into CVS. If anyone can think of a site that has good uptime and supports SVN, that would be much preferred to mucking with cvs. Especially given the propensity to renaming files...
There are a few things that need to happen.
The problem is doing it right requires a significant amount of time. Or so I had assumed.
At the moment I think a gradual approach is best.
I have no intentions of utterly abandoning drpy, but I do think moving it to a place where the community directs development rather than myself is far healthier and more sustainable in the long run.
Pleased to see that you are back in action. May I suggest that berliOS would be a good site for development. I notice that some other SourceForge projects use berliOS - presumably because there is an option to use SVN. I am using DrPython for the project that I have just started at berliOS: it can be found at http://luke-sdk.berlios.de
The development facilities are based on SourceForge and can be found at: http://developer.berlios.de
looks pretty nice. I will try to upload 161 with a few minor edits as a 3.11.x branch of drpy.
I think the general idea will be to confine development to minor patches, fixes, and the like.
Log in to post a comment.
Sign up for the SourceForge newsletter:
You seem to have CSS turned off.
Please don't fill out this field.