Re: Development tools and practices for Pythonistas
In article
<58a6bb1b-a98e-4c4a-86ea-09e040cb2...@r35g2000prj.googlegroups.com>,
snorble wrote:
> [standard tale of chaotic software development elided]
>
> I am aware of tools like version control systems, bug trackers, and
> things like these, but I'm not really sure if I need them, or how to
> use them properly.
None of this has anything to do with python. It's all standard software
engineering stuff that's the same with any language or technology.
Bug trackers are essential for large projects. For a one-man project,
it's probably more effort than it's worth. For the project I'm on now
(4 developers co-located with the customer), we're using a shared google
docs spreadsheet for bug tracking. It's free, low-overhead, and works
well enough. For a single person, even that may be more than you need.
On the other hand version control is essential from day zero, even on a
one-man project. There's plenty of perfectly good, free, systems out
there. The obvious choices are hg, git, and bzr. Pick one and use it.
The nice thing about them all is there's no lock-in. If you decide you
don't like the one you're using, you can easily convert your entire code
repository to any of the others without losing anything.
> I really like the idea of having a list of features, and tackling
> those features one at a time.
Yup, that's the core concept of all the agile development processes that
are all the rage these days. Sometimes called "release early and often".
> I read about people who do this, and
> each new features gets a new minor version number.
For the project I'm on, we don't even bother with version numbers. We
have a main branch which we (try to) keep stable and shippable at all
times, and push that to production whenever we've completed a feature
(or bug fix) that the customer needs. I see we're currently running:
9be3fc6a0e01cf128f63d1af2b19c180fb4eaacb (tip)
Version numbers make more sense with a traditional ("waterfall") type
process, where you design a bunch of stuff, write the code, go through a
testing and bug-fixing cycle, and the finally push it out the door.
> I think I just need some recommendations to help
> create a good mental map of what needs to happen, and mapping jargon
> to concepts. Like, "each feature gets its own directory". Or with a
> version control tool, I don't know if a feature maps to a branch, or a
> commit?
Well, start from the premise that you have a main branch which is always
shippable. That means the code runs and passes all the tests after
every single commit to that branch.
Now, when you need to make a change (add a feature or fix a bug), ask
yourself if the change is small enough that you can do all the work
required in one day. If so, then doing it in a single commit on your
main branch may make sense. If not, then spin up a development branch,
do the work there, and when you're satisfied it's shippable, merge it
onto your main branch.
--
http://mail.python.org/mailman/listinfo/python-list
Re: Development tools and practices for Pythonistas
On Apr 26, 7:39 pm, snorble wrote: > I'm not a Pythonista, but I aspire to be. > > My current tools: > > Python, gvim, OS file system > > My current practices: > > When I write a Python app, I have several unorganized scripts in a > directory (usually with several named test1.py, test2.py, etc., from > random ideas I have tested), and maybe a todo.txt file. Then I hack > away, adding features in a semi-random order. Then I get busy with > other things. Maybe one week I spend 20 hours on development. The next > week, no time on development. A few weeks later when I have some time, > I'm excited to get back to making progress, only to find that I have > to spend 30-60 minutes figuring out where I left off. The code is > usually out of sync with todo.txt. I see people who release new > versions and bug fixes, so I sometimes will create a new directory and > continue working from that copy, because it seems like the thing to > do. But if I ever made something worth releasing, and got a request > like, "I have problems with the 2.0 version. Can you send me the old > 1.1 version?" I'd be like, "uhhh... let me hunt through my files by > hand and get back to you in a month". I'm thinking I can do a lot > better than this. > > I am aware of tools like version control systems, bug trackers, and > things like these, but I'm not really sure if I need them, or how to > use them properly. I think having some organization to all of this > would help me to make more consistent progress, and spend less time > bringing myself up to speed after some time off. > > I really like the idea of having a list of features, and tackling > those features one at a time. I read about people who do this, and > each new features gets a new minor version number. It sounds very > organized and clean. But I'm not really sure of the best way to > achieve this. Mainly I think I just need some recommendations to help > create a good mental map of what needs to happen, and mapping jargon > to concepts. Like, "each feature gets its own directory". Or with a > version control tool, I don't know if a feature maps to a branch, or a > commit? > > I appreciate any advice or guidance anyone has to offer. Recently saw this: [Disclaimer: Not tried] http://labs.creativecommons.org/2010/11/10/bridging-public-bugtrackers-and-local-tasklists/ -- http://mail.python.org/mailman/listinfo/python-list
Python packaging (was Development tools and practices for Pythonistas)
On May 6, 2:59 pm, Tim Golden wrote: > On 06/05/2011 10:51, Jonathan Hartley wrote: > > > On Apr 26, 3:39 pm, snorble wrote: > >> I appreciate any advice or guidance anyone has to offer. > > > The 'Python Project HOWTO' gives good advice in terms of setting up a > > new project, what files and directories to create, what to put in > > version control, etc: > > >http://infinitemonkeycorps.net/docs/pph/ > > I'd forgotten about that. Great resource! Thanks for reminding me... > > TJG Thanks for that link. There is one question in this regard that is not covered: package-use Of course this http://infinitemonkeycorps.net/docs/pph/#id10 is there. But I am talking of setting up one's python environment. For example on a linux box how to best optimize using the native package manager (eg apt/rpm) along with packages from pypi. And when one needs to run with multiple pythons how to use virtualenv etc -- http://mail.python.org/mailman/listinfo/python-list
Re: Development tools and practices for Pythonistas
On 06/05/2011 10:51, Jonathan Hartley wrote: On Apr 26, 3:39 pm, snorble wrote: I appreciate any advice or guidance anyone has to offer. The 'Python Project HOWTO' gives good advice in terms of setting up a new project, what files and directories to create, what to put in version control, etc: http://infinitemonkeycorps.net/docs/pph/ I'd forgotten about that. Great resource! Thanks for reminding me... TJG -- http://mail.python.org/mailman/listinfo/python-list
Re: Development tools and practices for Pythonistas
On Apr 26, 3:39 pm, snorble wrote: > I appreciate any advice or guidance anyone has to offer. The 'Python Project HOWTO' gives good advice in terms of setting up a new project, what files and directories to create, what to put in version control, etc: http://infinitemonkeycorps.net/docs/pph/ Also, where I work we have tried many IDEs, but happily and productively use GVim and very little else, so don't feel you *have* to use an IDE. Best regards, Jonathan Hartley -- http://mail.python.org/mailman/listinfo/python-list
Re: Development tools and practices for Pythonistas
I use hg for even 50-line standalone python scripts. It's very well suited to these small environments, and scales up nicely. cd /my/working/dir hg init hg add myscript.py hg ci -m 'added myscript' It's that simple, and now hyou can go back if you make a terrible mistake, and you can post it to bitbucket and share with the world if you like, almost as easily. --Buck -- http://mail.python.org/mailman/listinfo/python-list
Re: Development tools and practices for Pythonistas
rusi writes: >> I actually use rcs in Windows. Needs a little setup, but works great, >> from Emacs VC-mode too. > > Where do you get it? > [What google is showing seems to be about 10-15 years old] As far as I know, RCS hasn't been updated since 5.7 which is about 10 years old now. Linux distributions also package the same version. I use the stuff from rcs57pc1.zip, at ftp://ftp.cs.purdue.edu/pub/RCS/ The package includes also comparison tools cmp, diff, diff3, sdiff as win32 versions. I suppose one would need to recompile if 64-bit versions were needed. The setup I mentioned was just setting RCSINIT to -x,v although I don't remember now why I needed that. -- http://mail.python.org/mailman/listinfo/python-list
Re: Development tools and practices for Pythonistas
On May 3, 11:19 pm, Anssi Saari wrote: > rusi writes: > > I am a bit surprised that no one has mentioned rcs so far > > Not an option if you are not on a *ix system and not something I am > > specifically recommending. > > I actually use rcs in Windows. Needs a little setup, but works great, > from Emacs VC-mode too. Where do you get it? [What google is showing seems to be about 10-15 years old] -- http://mail.python.org/mailman/listinfo/python-list
Re: Development tools and practices for Pythonistas
On May 2, 12:38 pm, Algis Kabaila wrote: > On Monday 02 May 2011 19:09:38 jacek2v wrote: > > > > > > > > > > > On May 2, 9:48 am, Algis Kabaila wrote: > > > On Monday 02 May 2011 17:19:57 rusi wrote: > > > > On May 2, 12:08 pm, Algis Kabaila > > > > wrote: > > > > > Actually, Bazaar is more convenient than rcs for a > > > > > single user, as the repository can be the working > > > > > directory (with a "hidden" .bzr directory that stores > > > > > diffs). > > > > > Dont exactly understand... > > > > Is it that you want it specifically hidden? > > > > Otherwise rcs will look inside an RCS directory just as > > > > bzr will with .bzr git will with .git and so on. > > > > Sorry for not being clear - "ls" will not show directories > > > that start with "." - in that sense these directories are > > > "hidden". They are not really really hidden, as "ls -l" > > > will show them. They simply are not in the way and keep > > > the progressive versions of the program (in form of > > > diffs). > > > "ls -l will not show directories that start with ".". > > "ls -a" will. > > > Regards > > Jacek > > Thanks - you are right - pardon my absent mindedness. > > -- > Algishttp://akabaila.pcug.org.au/StructuralAnalysis.pdf You're welcome :) -- http://mail.python.org/mailman/listinfo/python-list
Re: Development tools and practices for Pythonistas
rusi writes: > I am a bit surprised that no one has mentioned rcs so far > Not an option if you are not on a *ix system and not something I am > specifically recommending. I actually use rcs in Windows. Needs a little setup, but works great, from Emacs VC-mode too. -- http://mail.python.org/mailman/listinfo/python-list
Re: Development tools and practices for Pythonistas
Am 02.05.2011 01:33, schrieb David Boddie: After noting the warnings it contains, see the following page for a description of the Python API for Mercurial: http://mercurial.selenic.com/wiki/MercurialApi Ah, yes, no need to use os.sytem(), but all in all not much difference from doing so (and usage of CLI is recommended instead of using the API). I had a look at this page in 2009 and came to the conclusion that it's no good idea to use Mercurial as library. Seems that this still holds true. Git also has a Python API, which is fairly reasonable to use, though a bit different to the Mercurial one: http://www.samba.org/~jelmer/dulwich/ That looks more promising to me. I think I will try this and Bazaar to find which fits my needs better. Regards, Dietmar -- http://mail.python.org/mailman/listinfo/python-list
Re: Development tools and practices for Pythonistas
On Monday 02 May 2011 19:09:38 jacek2v wrote: > On May 2, 9:48 am, Algis Kabaila wrote: > > On Monday 02 May 2011 17:19:57 rusi wrote: > > > On May 2, 12:08 pm, Algis Kabaila > > > > wrote: > > > > Actually, Bazaar is more convenient than rcs for a > > > > single user, as the repository can be the working > > > > directory (with a "hidden" .bzr directory that stores > > > > diffs). > > > > > > Dont exactly understand... > > > Is it that you want it specifically hidden? > > > Otherwise rcs will look inside an RCS directory just as > > > bzr will with .bzr git will with .git and so on. > > > > Sorry for not being clear - "ls" will not show directories > > that start with "." - in that sense these directories are > > "hidden". They are not really really hidden, as "ls -l" > > will show them. They simply are not in the way and keep > > the progressive versions of the program (in form of > > diffs). > > "ls -l will not show directories that start with ".". > "ls -a" will. > > Regards > Jacek Thanks - you are right - pardon my absent mindedness. -- Algis http://akabaila.pcug.org.au/StructuralAnalysis.pdf -- http://mail.python.org/mailman/listinfo/python-list
Re: Development tools and practices for Pythonistas
On May 2, 9:48 am, Algis Kabaila wrote: > On Monday 02 May 2011 17:19:57 rusi wrote: > > > On May 2, 12:08 pm, Algis Kabaila > wrote: > > > Actually, Bazaar is more convenient than rcs for a single > > > user, as the repository can be the working directory (with > > > a "hidden" .bzr directory that stores diffs). > > > Dont exactly understand... > > Is it that you want it specifically hidden? > > Otherwise rcs will look inside an RCS directory just as bzr > > will with .bzr git will with .git and so on. > > Sorry for not being clear - "ls" will not show directories that > start with "." - in that sense these directories are "hidden". > They are not really really hidden, as "ls -l" will show them. > They simply are not in the way and keep the progressive versions > of the program (in form of diffs). "ls -l will not show directories that start with ".". "ls -a" will. Regards Jacek -- http://mail.python.org/mailman/listinfo/python-list
Re: Development tools and practices for Pythonistas
On Monday 02 May 2011 17:19:57 rusi wrote: > On May 2, 12:08 pm, Algis Kabaila wrote: > > Actually, Bazaar is more convenient than rcs for a single > > user, as the repository can be the working directory (with > > a "hidden" .bzr directory that stores diffs). > > Dont exactly understand... > Is it that you want it specifically hidden? > Otherwise rcs will look inside an RCS directory just as bzr > will with .bzr git will with .git and so on. Sorry for not being clear - "ls" will not show directories that start with "." - in that sense these directories are "hidden". They are not really really hidden, as "ls -l" will show them. They simply are not in the way and keep the progressive versions of the program (in form of diffs). Does that make better sense?. -- Algis http://akabaila.pcug.org.au/StructuralAnalysis.pdf -- http://mail.python.org/mailman/listinfo/python-list
Re: Development tools and practices for Pythonistas
On May 2, 12:08 pm, Algis Kabaila wrote: > > Actually, Bazaar is more convenient than rcs for a single user, > as the repository can be the working directory (with a "hidden" > .bzr directory that stores diffs). Dont exactly understand... Is it that you want it specifically hidden? Otherwise rcs will look inside an RCS directory just as bzr will with .bzr git will with .git and so on. -- http://mail.python.org/mailman/listinfo/python-list
Re: Development tools and practices for Pythonistas
On Monday 02 May 2011 13:22:44 Ben Finney wrote: > rusi writes: > > You may want to look at rcs if you are in the space where > > But today, Bazaar or Mercurial fill that role just as well: > quick simple set up, good tool support (yes, even in Emacs > using VC mode), and easy to use for easy things. > Actually, Bazaar is more convenient than rcs for a single user, as the repository can be the working directory (with a "hidden" .bzr directory that stores diffs). I had to use git, too, because some projects use git for their version control (viz PySide, Nokia's tool to replace PyQt). IMHO there is not much to pick between git and Bazaar and hg is also rather similar. The remaining doubts are betwwed the Distributed Version Control and the more traditional Subversion, which is also quite nice, even for a single user. OldAl. -- Algis http://akabaila.pcug.org.au/StructuralAnalysis.pdf -- http://mail.python.org/mailman/listinfo/python-list
Re: Development tools and practices for Pythonistas
On May 2, 8:22 am, Ben Finney wrote: > rusi writes: > > You may want to look at rcs if you are in the space where you want: > > -- something better than tarballs > > -- no pretensions beyond single-user, single-machine, (almost)single- > > file usage (ie small scale) > > -- something that integrates nicely with emacs > > I might have agreed ten years ago; compared to CVS or Subversion, RCS is > simpler to use and set up and had lower workflow overhead. > > But today, Bazaar or Mercurial fill that role just as well: quick simple > set up, good tool support (yes, even in Emacs using VC mode), and easy > to use for easy things. > > I really don't see any benefit to using RCS for even a lone hacker > tracking files; Bazaar or Mercurial fill that role just as well, and > continue to work well as your needs grow. In a word: single files. If you have a directory with a number of short unrelated scripts -- python, shell etc -- the philosophy: vcs-manages-projects-not-files is a nuisance not a help. And which is why things like zit http://git.oblomov.eu/zit have arisen: the need to go back from bzr/git/hg to (something like) rcs -- http://mail.python.org/mailman/listinfo/python-list
Re: Development tools and practices for Pythonistas
rusi writes: > You may want to look at rcs if you are in the space where you want: > -- something better than tarballs > -- no pretensions beyond single-user, single-machine, (almost)single- > file usage (ie small scale) > -- something that integrates nicely with emacs I might have agreed ten years ago; compared to CVS or Subversion, RCS is simpler to use and set up and had lower workflow overhead. But today, Bazaar or Mercurial fill that role just as well: quick simple set up, good tool support (yes, even in Emacs using VC mode), and easy to use for easy things. I really don't see any benefit to using RCS for even a lone hacker tracking files; Bazaar or Mercurial fill that role just as well, and continue to work well as your needs grow. -- \ “Philosophy is questions that may never be answered. Religion | `\ is answers that may never be questioned.” —anonymous | _o__) | Ben Finney -- http://mail.python.org/mailman/listinfo/python-list
Re: Development tools and practices for Pythonistas
On Apr 30, 8:21 am, CM wrote: > > A lone developer using such a VCS reaps the benefits of this by getting > > good merging support. > > While we're on the topic, when should a lone developer bother to start > using a VCS? At what point in the complexity of a project (say a hobby > project, but > a somewhat seriousish one, around ~5-9k LOC) is the added > complexity of bringing a VCS into it worth it? When you hit your first bug? Ok seriously, when you hit your first serious bug maybe? I am a bit surprised that no one has mentioned rcs so far Not an option if you are not on a *ix system and not something I am specifically recommending. [I grew up on rcs 15 years ago but not used it much of late] You may want to look at rcs if you are in the space where you want: -- something better than tarballs -- no pretensions beyond single-user, single-machine, (almost)single- file usage (ie small scale) -- something that integrates nicely with emacs -- http://mail.python.org/mailman/listinfo/python-list
Re: Development tools and practices for Pythonistas
>> > Look at the big two sites for open-source repositories -- github and >> > bitbucket. > Note that there are three: Launchpad (backed by Bazaar) is the other > “big site” for free-software project hosting. There is also patch-tag.com (using darcs) though it is smaller. -- http://mail.python.org/mailman/listinfo/python-list
Re: Development tools and practices for Pythonistas
On Sunday 01 May 2011 18:11, Dietmar Schwertberger wrote: > Am 01.05.2011 02:47, schrieb Shawn Milochik: >> Look at the big two sites for open-source repositories -- github and >> bitbucket. One's git, the other Mercurial. I don't think you can go >> wrong picking either one. > > Can any of those be used from Python as a library, i.e. something like > import Hg > r = Hg.open(path) > > When I had a look at Mercurial, which is implemented in Python, > it was implemented in a way that I could not do that. It was implemented > as rather monolithic program which could be used from os.system(...) > only. After noting the warnings it contains, see the following page for a description of the Python API for Mercurial: http://mercurial.selenic.com/wiki/MercurialApi Git also has a Python API, which is fairly reasonable to use, though a bit different to the Mercurial one: http://www.samba.org/~jelmer/dulwich/ I've used both with some success. David -- http://mail.python.org/mailman/listinfo/python-list
Re: Development tools and practices for Pythonistas
Dietmar Schwertberger writes: > Am 01.05.2011 02:47, schrieb Shawn Milochik: > > Look at the big two sites for open-source repositories -- github and > > bitbucket. Note that there are three: Launchpad (backed by Bazaar) is the other “big site” for free-software project hosting. > Can any of those be used from Python as a library, i.e. something like > import Hg > r = Hg.open(path) I haven't used it, but Launchpad (the Canonical project hosting which uses Bazaar for the VCS) is of course well-supported in the Bazaar libraries. Access to the hosting site is eminently programmable with a good API, by all accounts. -- \“It is seldom that liberty of any kind is lost all at once.” | `\ —David Hume | _o__) | Ben Finney -- http://mail.python.org/mailman/listinfo/python-list
Re: Development tools and practices for Pythonistas
On Sun, May 01 2011, Dietmar Schwertberger wrote: > Am 01.05.2011 02:47, schrieb Shawn Milochik: >> Look at the big two sites for open-source repositories -- github and >> bitbucket. One's git, the other Mercurial. I don't think you can go >> wrong picking either one. > > Can any of those be used from Python as a library, i.e. something like > import Hg > r = Hg.open(path) > > When I had a look at Mercurial, which is implemented in Python, it was > implemented in a way that I could not do that. It was implemented as > rather monolithic program which could be used from os.system(...) > only. > > With a good API, I could easily have integrated it into my development > flow. I have a codebase which is shared between different projects and > there are many small changes on many different PCs. In theory a > distributed VCS is good at supporting that, but in practice I went > back to my lightweight synchronization scripts and file storage > again. With the API, I could have best of both worlds. You should take a look at Bazaar. I found it fairly easy to use bzrlib from my own Python scripts. http://people.canonical.com/~mwh/bzrlibapi/ Jason -- http://mail.python.org/mailman/listinfo/python-list
Re: [OT] VCS for non-text (was Development tools and practices for Pythonistas)
On 2011-04-30, Tim Chase wrote: > On 04/30/2011 04:15 AM, Martin Schöön wrote: >> You guys are very code focused, which is natural given where we are. >> >> Having absorbed what I have seen here, looked a little at Mercurial, >> read a little on the webs of Fossil and Bazaar I start to think there >> is great merit in all this VCS stuff for other types of projects. >> >> At work my projects contain very little coding (some Python, some >> matlab/scilab perhaps) but a fair amount of CAD/CAE, written >> reports, presentations (OpenOffice and that other Office), >> spread sheets etc etc. A mixture of ascii-files and various >> proprietary formats most of which is stored in binary form. >> Some of the CAE-work generate pretty big files stored >> in dynamically created subdirectories. > > For non-text blobs, it takes a little bit of insight to get the > most out of them. For OpenDocument (Open/Libre Office > documents), they're zipped files containing text/XML which can be > diff'ed with more meaning. Usually there are custom filters for > git[1], Mercurial[2] and Bazaar[3] which will unpack the zipped > file contents before committing and give you more sensible diffs. > Likewise, for images (gif/jpg/tiff/raw/etc), there are > particular image-diff programs which make it easier to tell what > happened, as the textual diff of binary files is pretty useless. > However some images (such as .svg files) are XML/text inside, > and diff pretty nicely without extra effort. > > I can't speak to CAD/CAE, but it would have to be addressed on a > per-format basis in your given VCS. That said, you *can* store > the binary blobs in each, it's just not as useful without > meaningful comparisons. > > -tkc > > [1] > http://kerneltrap.org/mailarchive/git/2008/9/15/3305014 > > [2] > http://mercurial.selenic.com/wiki/HandlingOpenDocumentFiles > > [3] > http://doc.bazaar.canonical.com/plugins/en/oodiff.html > All very useful information. Thank you for that Tim. /Martin -- http://mail.python.org/mailman/listinfo/python-list
Re: Development tools and practices for Pythonistas
Am 01.05.2011 02:47, schrieb Shawn Milochik: Look at the big two sites for open-source repositories -- github and bitbucket. One's git, the other Mercurial. I don't think you can go wrong picking either one. Can any of those be used from Python as a library, i.e. something like import Hg r = Hg.open(path) When I had a look at Mercurial, which is implemented in Python, it was implemented in a way that I could not do that. It was implemented as rather monolithic program which could be used from os.system(...) only. With a good API, I could easily have integrated it into my development flow. I have a codebase which is shared between different projects and there are many small changes on many different PCs. In theory a distributed VCS is good at supporting that, but in practice I went back to my lightweight synchronization scripts and file storage again. With the API, I could have best of both worlds. Regards, Dietmar -- http://mail.python.org/mailman/listinfo/python-list
Re: Development tools and practices for Pythonistas
For what it's worth, the Python core developers have selected Mercurial. I personally use git and love it. Most open-source people seem to use one or the other of the two. They're pretty similar in most ways. Look at the big two sites for open-source repositories -- github and bitbucket. One's git, the other Mercurial. I don't think you can go wrong picking either one. -- http://mail.python.org/mailman/listinfo/python-list
Re: Development tools and practices for Pythonistas
Roy Smith writes: > No need to use VCS at the very beginning of a project. You can easily > wait until you've written 10 or 20 lines of code :-) +1 QOTW > > Should I bother to try a VCS? > > Absolutely. Even if you don't need it for a small one-person project, > it's a good habit to get into. Yes. Learn to use each of the top-tier VCS options: Bazaar, Git, Mercurial. Learn to use one of them well (my choice is Bazaar, as explored elsewhere in this thread). -- \ “Whenever you read a good book, it's like the author is right | `\ there, in the room talking to you, which is why I don't like to | _o__) read good books.” —Jack Handey | Ben Finney -- http://mail.python.org/mailman/listinfo/python-list
Re: [OT] VCS for non-text (was Development tools and practices for Pythonistas)
On 04/30/2011 04:15 AM, Martin Schöön wrote: You guys are very code focused, which is natural given where we are. Having absorbed what I have seen here, looked a little at Mercurial, read a little on the webs of Fossil and Bazaar I start to think there is great merit in all this VCS stuff for other types of projects. At work my projects contain very little coding (some Python, some matlab/scilab perhaps) but a fair amount of CAD/CAE, written reports, presentations (OpenOffice and that other Office), spread sheets etc etc. A mixture of ascii-files and various proprietary formats most of which is stored in binary form. Some of the CAE-work generate pretty big files stored in dynamically created subdirectories. For non-text blobs, it takes a little bit of insight to get the most out of them. For OpenDocument (Open/Libre Office documents), they're zipped files containing text/XML which can be diff'ed with more meaning. Usually there are custom filters for git[1], Mercurial[2] and Bazaar[3] which will unpack the zipped file contents before committing and give you more sensible diffs. Likewise, for images (gif/jpg/tiff/raw/etc), there are particular image-diff programs which make it easier to tell what happened, as the textual diff of binary files is pretty useless. However some images (such as .svg files) are XML/text inside, and diff pretty nicely without extra effort. I can't speak to CAD/CAE, but it would have to be addressed on a per-format basis in your given VCS. That said, you *can* store the binary blobs in each, it's just not as useful without meaningful comparisons. -tkc [1] http://kerneltrap.org/mailarchive/git/2008/9/15/3305014 [2] http://mercurial.selenic.com/wiki/HandlingOpenDocumentFiles [3] http://doc.bazaar.canonical.com/plugins/en/oodiff.html -- http://mail.python.org/mailman/listinfo/python-list
Re: Development tools and practices for Pythonistas
On 2011-04-30, Hans Georg Schaathun wrote: > On Fri, 29 Apr 2011 20:21:58 -0700 (PDT), CM > wrote: >: While we're on the topic, when should a lone developer bother to start >: using >: a VCS? At what point in the complexity of a project (say a hobby >: project, but >: a somewhat seriousish one, around ~5-9k LOC) is the added complexity >: of >: bringing a VCS into it worth it? > > You are asking the wrong question. It depends relatively little on the > number of lines, and much more on what you are likely to do with it. > You guys are very code focused, which is natural given where we are. Having absorbed what I have seen here, looked a little at Mercurial, read a little on the webs of Fossil and Bazaar I start to think there is great merit in all this VCS stuff for other types of projects. At work my projects contain very little coding (some Python, some matlab/scilab perhaps) but a fair amount of CAD/CAE, written reports, presentations (OpenOffice and that other Office), spread sheets etc etc. A mixture of ascii-files and various proprietary formats most of which is stored in binary form. Some of the CAE-work generate pretty big files stored in dynamically created subdirectories. Our computer environment is mostly based on Vista and Suse Linux and I still have a SUN Solaris machine in my office but probably not for long. Given this type of scenario, what VCS tools should I consider? Still the Mercurial/Git/Bazaar/Fossil crowd? Any one of those ruled out and then why? /Martin -- http://mail.python.org/mailman/listinfo/python-list
Re: Development tools and practices for Pythonistas
On Fri, 29 Apr 2011 20:21:58 -0700 (PDT), CM wrote: : While we're on the topic, when should a lone developer bother to start : using : a VCS? At what point in the complexity of a project (say a hobby : project, but : a somewhat seriousish one, around ~5-9k LOC) is the added complexity : of : bringing a VCS into it worth it? You are asking the wrong question. It depends relatively little on the number of lines, and much more on what you are likely to do with it. One thing is certain. If you are ever going to want to use a VCS, you can just as well start yesterday. Using a VCS is not an extra hassle to use. Only an added hassle to get started with. Personally I use the VCS as 1) My backup system; naturally doing incremental backups only. 2) A means to synchronise multiple boxes (not just my laptop and my desktop, sometimes a linux and a mac system, and dedicated number crunchers too), and merge changes made out of synch. 3) The possibility to make one branch to run a suite of jobs which may take a week or more, and still continue development independently on the main branch. As you can see, the number of lines is irrelevant. 1-2 mean that everything is VC-d, not only code for which the VCS is meant. And 3 is of course about what kind of code. I branch rather little. Programming is not my day job -- nor my main hobby, and I simply have not got the capacity to keep track of multiple branches. Even at 12-15kloc I have little use of the VCS for its intended purposes. If you take your development project more seriously, you may do more of that within the first 500 loc... But then, using VCS is not sufficient. You need to /think/ VC. In other words, taking up a VCS when the system is large enough to require it is too late. You need time to learn the thinking. -- :-- Hans Georg -- http://mail.python.org/mailman/listinfo/python-list
Re: Development tools and practices for Pythonistas
In article , CM wrote: > While we're on the topic, when should a lone developer bother to start > using a VCS? No need to use VCS at the very beginning of a project. You can easily wait until you've written 10 or 20 lines of code :-) > Should I bother to try a VCS? Absolutely. Even if you don't need it for a small one-person project, it's a good habit to get into. If you haven't used any, my recommendation would be hg. Partly because it's powerful, and partly because it's relatively easy to use. The other popular choice these days would be git. Hg and git are pretty similar, and between the two of them probably cover 90% of current usage. Unless you've got a specific reason to try something else (i.e. a project you're interested in uses something else), those seem like the only two reasonable choices. -- http://mail.python.org/mailman/listinfo/python-list
Re: Development tools and practices for Pythonistas
Depends on the project, but I'd start with git the time I created the first file in my project. If you're in the habit of committing then you can easily rollback missteps. If you're in the habit of making branches you can experiment without breaking the currently-working code. -- http://mail.python.org/mailman/listinfo/python-list
Re: Development tools and practices for Pythonistas
> A lone developer using such a VCS reaps the benefits of this by getting > good merging support. While we're on the topic, when should a lone developer bother to start using a VCS? At what point in the complexity of a project (say a hobby project, but a somewhat seriousish one, around ~5-9k LOC) is the added complexity of bringing a VCS into it worth it? I've been making changes to code and saving changes to the same files, but backing up on Dropbox, which keeps 30 days of previous saves. I've rarely had to resort to undoing code by calling up a previous save. I test each new change as it is made to see if it breaks anything (not automatic testing, though), and I don't collaborate with anyone else as yet. Should I bother to try a VCS? -- http://mail.python.org/mailman/listinfo/python-list
Re: Development tools and practices for Pythonistas
Hans Georg Schaathun writes: > Exactly, and with svn that can be a true nightmare when directories > are involved. The rumour is that git handles this much better. Any of the top-tier distributed VCS (Bazaar, Git, Mercurial) handle branching and merging very well. They have to, because branching and merging is much more frequent and casual in a distributed VCS. A lone developer using such a VCS reaps the benefits of this by getting good merging support. -- \ “If consumers even know there's a DRM, what it is, and how it | `\ works, we've already failed.” —Peter Lee, Disney corporation, | _o__) 2005 | Ben Finney -- http://mail.python.org/mailman/listinfo/python-list
Re: Development tools and practices for Pythonistas
On Wed, 27 Apr 2011 14:24:30 +0200, Jean-Michel Pichavant wrote: : I was talking about merge *issue* i.e merge resulting in conflicts that : are not easy to solve. With a single user most of the merge will be : solved automatically by any decent VCS. Exactly, and with svn that can be a true nightmare when directories are involved. The rumour is that git handles this much better. I call it a rumour not because I doubt it (I don't), but because I have not seen for myself. -- :-- Hans Georg -- http://mail.python.org/mailman/listinfo/python-list
Re: [OT] Comparing VCS tools (was ""Development tools and practices for Pythonistas")
We were looking for some simple integrated SCM, issue tracker and wiki in our university for software design and software testing courses, and fossil seems to be perfect match, thanks for sharing. -- With best regards, Daniel Kluev -- http://mail.python.org/mailman/listinfo/python-list
Re: [OT] Comparing VCS tools (was ""Development tools and practices for Pythonistas")
Fossil is another SCM to consider: http://www.fossil-scm.org/ It's written by the author of SQLite, D. Richard Hipp. It's not as well-known as some of the other DCVS's, but the Tcl/Tk language projects have moved their core development to it (http://core.tcl.tk). This is relevant to Python because Tkinter is part of the stlib. There aren't any huge sites like Github providing Fossil hosting, but here is one site: http://chiselapp.com/ --Kevin -- Kevin Walzer Code by Kevin http://www.codebykevin.com -- http://mail.python.org/mailman/listinfo/python-list
Re: [OT] VCS tools (was "Development tools and practices for Pythonistas")
This has been a pretty informative thread so far. Please keep it coming. I am a hardware development guy and do very little software development. I have been vaguely aware of tools for version control but inspired by this thread I have started looking at Mercurial. My humble contribution (from my boss really) since I have not seen it mentioned here: http://code.google.com/p/gource/ (I have zero experience of gource so there is no point in asking me questions) /Martin -- http://mail.python.org/mailman/listinfo/python-list
Re: Development tools and practices for Pythonistas
Thomas Rachel writes: > Am 27.04.2011 13:17, schrieb Jean-Michel Pichavant: > > > You're mistaking, SVN is not restricted to solo work. However it's > > more suitable for solo work than git. > > Why? > > I personally found hg much better than svn. That's why I migrated all > my projects. Indeed. The only thing left that Subversion is better at than the three modern top-tier VCSen is working with existing Subversion legacy repositories. Even for that, ‘bzr-svn’ and ‘git-svn’ work admirably well. -- \ “Nullius in verba” (“Take no-one's word for it”) —motto of the | `\ Royal Society, since 1663-06-30 | _o__) | Ben Finney -- http://mail.python.org/mailman/listinfo/python-list
Re: [OT] VCS tools (was "Development tools and practices for Pythonistas")
On 04/27/2011 04:24 AM, Jean-Michel Pichavant wrote: Ben Finney wrote: Mercurial – are the ones to choose from. Anoyone recommending a VCS tool that has poor merging support (such as Subversion or, heaven help us, CVS) is doing the newcomer a disservice. True enough. But the modern crop of first-tier VCSen – Bazaar, Git, For a single user, there would be no merge issue. And svn is very simple to use. There have been plenty of times I've needed to merge in SVN as a solo developer. Usually I'll branch off maint. branches and spin out feature branches. For the maint. branches, I want to apply hot-fixes to the branch and then merge those hot-fixes into the dev mainline. For the feature branches, I want to be able to flip between mainline development and feature development without one interfering with the other, but then easily pull changes from one to the other. And it's always been a pain. While I understand more recent SVN releases should auto-mark things in a way that merging is less painful, I find that it doesn't come remotely close to the ease with which I can merge in other systems. -tkc -- http://mail.python.org/mailman/listinfo/python-list
Re: Development tools and practices for Pythonistas
Am 27.04.2011 13:17, schrieb Jean-Michel Pichavant: You're mistaking, SVN is not restricted to solo work. However it's more suitable for solo work than git. Why? I personally found hg much better than svn. That's why I migrated all my projects. Thomas -- http://mail.python.org/mailman/listinfo/python-list
Re: Development tools and practices for Pythonistas
Anssi Saari wrote: Jean-Michel Pichavant writes: For a single user, there would be no merge issue. Really? What about a single user with many computers and environments? I find myself merging files on occasion because I edited them separately and forgot to check in changes before doing more edits on a different computer. I was talking about merge *issue* i.e merge resulting in conflicts that are not easy to solve. With a single user most of the merge will be solved automatically by any decent VCS. JM -- http://mail.python.org/mailman/listinfo/python-list
Re: Development tools and practices for Pythonistas
Jean-Michel Pichavant writes: > Ben Finney wrote: > > Mercurial – are the ones to choose from. Anoyone recommending a VCS tool > > that has poor merging support (such as Subversion or, heaven help us, > > CVS) is doing the newcomer a disservice. > > True enough. But the modern crop of first-tier VCSen – Bazaar, > > Git, > For a single user, there would be no merge issue. And svn is very > simple to use. Bazaar and Mercurial are also simple to use, and you won't have to un-learn them when you want a good VCS for collaboration. > That would not be a such bad advice for a beginner with VCS systems. I disagree; a beginner can just as easily learn a better VCS and avoid the bad habits that come along with lesser tools. -- \ “Theology is the effort to explain the unknowable in terms of | `\ the not worth knowing.” —Henry L. Mencken | _o__) | Ben Finney -- http://mail.python.org/mailman/listinfo/python-list
Re: Development tools and practices for Pythonistas
Jean-Michel Pichavant writes: > For a single user, there would be no merge issue. Really? What about a single user with many computers and environments? I find myself merging files on occasion because I edited them separately and forgot to check in changes before doing more edits on a different computer. -- http://mail.python.org/mailman/listinfo/python-list
Re: Development tools and practices for Pythonistas
Chris Angelico wrote: On Wed, Apr 27, 2011 at 7:24 PM, Jean-Michel Pichavant wrote: For a single user, there would be no merge issue. And svn is very simple to use. That would not be a such bad advice for a beginner with VCS systems. As someone who for years had "nightly backups and renamed files" as his only VCS, I would advise beginners to pick up a VCS that they can learn, master, and then use widely, not one that will be restricted to solo work (forcing them to learn a different system when they join some other project). There's no particular benefit in learning older systems, is there? (I never learned CVS or SVN; my first is git, and it's the only one I've used to any great extent.) Oh, and rolling your own VCS can work in specific situations, but it's probably going to work out a lot more efficient to use a well-known one, even if it does have a learning curve. I have a few places where I should probably migrate things to git. Chris Angelico You're mistaking, SVN is not restricted to solo work. However it's more suitable for solo work than git. Git is just the current buzz about VCS. I guess some people are switching to it without really knowing what's going on. http://en.wikipedia.org/wiki/Comparison_of_revision_control_software I tried to search for indicators about VCS usage without finding any but I think that svn is still one the most used VCS. Anyway it's not about which one is the most popular, but which one fits your need the best. For the OP, that would be SVN IMO. JM -- http://mail.python.org/mailman/listinfo/python-list
Re: Development tools and practices for Pythonistas
On Wed, Apr 27, 2011 at 7:24 PM, Jean-Michel Pichavant wrote: > For a single user, there would be no merge issue. And svn is very simple to > use. > That would not be a such bad advice for a beginner with VCS systems. As someone who for years had "nightly backups and renamed files" as his only VCS, I would advise beginners to pick up a VCS that they can learn, master, and then use widely, not one that will be restricted to solo work (forcing them to learn a different system when they join some other project). There's no particular benefit in learning older systems, is there? (I never learned CVS or SVN; my first is git, and it's the only one I've used to any great extent.) Oh, and rolling your own VCS can work in specific situations, but it's probably going to work out a lot more efficient to use a well-known one, even if it does have a learning curve. I have a few places where I should probably migrate things to git. Chris Angelico -- http://mail.python.org/mailman/listinfo/python-list
Re: Development tools and practices for Pythonistas
Ben Finney wrote: Mercurial – are the ones to choose from. Anoyone recommending a VCS tool that has poor merging support (such as Subversion or, heaven help us, CVS) is doing the newcomer a disservice. True enough. But the modern crop of first-tier VCSen – Bazaar, Git, For a single user, there would be no merge issue. And svn is very simple to use. That would not be a such bad advice for a beginner with VCS systems. JM -- http://mail.python.org/mailman/listinfo/python-list
Re: recommended Emacs mode (was Re: Development tools and practices for Pythonistas)
On Apr 27, 11:39 am, Gour-Gadadhara Dasa wrote: > On Tue, 26 Apr 2011 07:39:41 -0700 (PDT) > > snorble wrote: > > I'm not a Pythonista, but I aspire to be. > > > My current tools: > > > Python, gvim, OS file system > > I'm also starting with Python after abandoning idea to use D for our > desktop GUI application. > > We plan to use Python + Qt along with Cython extensions and wrapping > external C library. > > I'm interested which Python mode can you recommend for Emacs: > > a) python.el > > b) python-mode.el or Thats what I use. > > c) 'new' python.el (https://github.com/fgallina/python.el) Looks interesting -- first time I am hearing... > > considering our needs above and desire to use IPython running > Emacs-23.2 on FreeBSD? -- http://mail.python.org/mailman/listinfo/python-list
recommended Emacs mode (was Re: Development tools and practices for Pythonistas)
On Tue, 26 Apr 2011 07:39:41 -0700 (PDT) snorble wrote: > I'm not a Pythonista, but I aspire to be. > > My current tools: > > Python, gvim, OS file system I'm also starting with Python after abandoning idea to use D for our desktop GUI application. We plan to use Python + Qt along with Cython extensions and wrapping external C library. I'm interested which Python mode can you recommend for Emacs: a) python.el b) python-mode.el or c) 'new' python.el (https://github.com/fgallina/python.el) considering our needs above and desire to use IPython running Emacs-23.2 on FreeBSD? Sincerely, Gour -- “In the material world, conceptions of good and bad are all mental speculations…” (Sri Caitanya Mahaprabhu) http://atmarama.net | Hlapicina (Croatia) | GPG: 52B5C810 signature.asc Description: PGP signature -- http://mail.python.org/mailman/listinfo/python-list
Re: Comparing VCS tools (was ""Development tools and practices for Pythonistas")
rusi wrote: > What's the facts? Anyone with any experiences on this? No experience, but I'm rather torn over Fossil. On the one hand, it feels like NIH writ large; on the other hand, it's a DVCS with Trac- like features in a standalone executable less than 1MB in size...by the author of sqlite. -- http://mail.python.org/mailman/listinfo/python-list
Re: Comparing VCS tools (was ""Development tools and practices for Pythonistas")
On Apr 27, 6:44 am, Tim Chase wrote: > On 04/26/2011 01:42 PM, Algis Kabaila wrote: > > > Thomas, have you tried bzr (Bazaar) and if so do you consider hg > > (Mercurial) better? > > > And why is it better? (bzr is widely used in ubuntu, which is > > my favourite distro at present). > > Each of the main 3 (bzr, hg, git) have advantages and > disadvantages. As Ben (and others?) mentions, it's best to learn > one of these instead of starting with something like Subversion > or worse (CVS or worse, *shudder* MS Visual SourceSafe) The distributed revision control page on wikipedia (bottom) http://en.wikipedia.org/wiki/Distributed_revision_control in addition to these, mentions fossil -- something I had not heard of till now. Its claims seem to match the OPs lightweight requirements more closely than any other: (from above link) --- Fossil is cross-platform; its source code compiles on Linux, Mac OS X and Microsoft Windows. It is not only capable of distributed version control like Git and Mercurial but also supports distributed bug tracking, a distributed wiki and a distributed blog mechanism all in a single integrated package. With its built-in and easy-to-use web interface, Fossil simplifies project tracking and promotes situational awareness. A user may simply type "fossil ui" from within any check- out and Fossil automatically opens the user's web browser in a page that gives detailed history and status information on that project. -- Well so much for the claims :-) What's the facts? Anyone with any experiences on this? -- http://mail.python.org/mailman/listinfo/python-list
Re: [OT] Comparing VCS tools (was ""Development tools and practices for Pythonistas")
On 04/26/2011 01:42 PM, Algis Kabaila wrote: Thomas, have you tried bzr (Bazaar) and if so do you consider hg (Mercurial) better? And why is it better? (bzr is widely used in ubuntu, which is my favourite distro at present). Each of the main 3 (bzr, hg, git) have advantages and disadvantages. As Ben (and others?) mentions, it's best to learn one of these instead of starting with something like Subversion or worse (CVS or worse, *shudder* MS Visual SourceSafe) Bazaar (bzr) launchpad.net popular for hosting Pros: - some Ubuntu interactions (such as launchpad) easier - a rigorous focus on correctness - written in Python (with a small optional bit of C) - easy-to-use interface (CVS-ish) - good cross-platform support Cons: - was slow, though I understand they've worked on improving this Protocols: - custom/smart protocol - http - sftp - ftp - rsync (via plugin) Mercurial (hg) == BitBucket is popular for hosting Pros: - speedy - written in Python (with a small optional bit of C) - easy-to-use interface (CVS-ish) - fairly compact repositories - EXCELLENT documentation via online book - chosen by Python as the repository of choice - good cross-platform support Cons: - no biggies that I've found Protocols: - http - ssh Git (git) = GitHub is popular for hosting Pros: - a *lot* of popular projects use it (Linux kernel) - fast - fairly compact repositories - good documentation (though somewhat scattered) Cons: - interface diverges from the "CVS standards" - (was?) not native on - repositories require periodic maintenance using git gc - Win32 support is/was a little clunky - interface was under tumultuous change for a while (though it seems to have stabilized now) Protocols: - custom/smart protocol - http - sftp - ftp So that said, I've become a Mercurial user because the interface was close to SVN which I used previously, and it was speedy on my older machines. If bzr has come up to comparable speed, I'd be game to probe it again. I just don't care for git's command-line UI, but that's a personal preference thing (just like I prefer vi/vim over emacs, but acknowledge there are lots of smart folks on the other side, too). -tkc For at least hg vs. git, see http://stackoverflow.com/questions/1598759/git-and-mercurial-compare-and-contrast -- http://mail.python.org/mailman/listinfo/python-list
Re: Development tools and practices for Pythonistas
On Wednesday 27 April 2011 09:41:53 Ben Finney wrote: > Chris Angelico writes: > > As other people have said, version control is very handy. I > > use git myself, but imho the choice of _which_ VCS you use > > is far less important than the choice of _whether_ to use > > one. > > True enough. But the modern crop of first-tier VCSen – > Bazaar, Git, Mercurial – are the ones to choose from. > Anoyone recommending a VCS tool that has poor merging > support (such as Subversion or, heaven help us, CVS) is > doing the newcomer a disservice. > All golden advice! Two things were not mentioned: 1. Work on an existing project that is based on Python. The "Launchpad" of ubuntu has a great environment for a project. There are many existing projects in which to participate. Even Bazaar's GUI version is programmed in Python with PyQt for the GUI proper. You will get a lot out of participation in an existing project, probably a lot more than you input. Ultimately it is how much you input that is of of most benefit to you yourself. 2. I failed to see questions and suggestions of platform to work from. Your experience, interests, and computer platform will determine what is useful to you and what is less useful. 3. Finally, it is important to have a project about which you can master enough enthusiasm to persist. "What project " depends very much on item 2. May the favourable wind fill your sails, OldAl. -- Algis http://akabaila.pcug.org.au/StructuralAnalysis.pdf -- http://mail.python.org/mailman/listinfo/python-list
Re: Development tools and practices for Pythonistas
Chris Angelico writes: > As other people have said, version control is very handy. I use git > myself, but imho the choice of _which_ VCS you use is far less > important than the choice of _whether_ to use one. True enough. But the modern crop of first-tier VCSen – Bazaar, Git, Mercurial – are the ones to choose from. Anoyone recommending a VCS tool that has poor merging support (such as Subversion or, heaven help us, CVS) is doing the newcomer a disservice. Learn the basics in all three of those, and learn one of them well. My choice is Bazaar, because it has a very friendly command-line interface and has excellent support for repositories created by all the others :-) > def function(parms): > # TODO: This should check if Foo matches Bar and shortcut the computation > ... > > I have a very strict format: T, O, D, O, literal ASCII, always > uppercase. Makes it easy to grep (and I try to avoid "todo" in > lower-case, which means I can use a case-insensitive search if I > choose). Note that following that specific convention will match the default in many programmers's text editors for highlighting those entries to bring them to the programmer's attention. The defaults for PyLint also report such comments in the code. > Ultimately, it all comes down to discipline, and how important the > project is to you. At work, I have a lot of disciplines; we have a > wiki where stuff gets documented, we have source control, we have > daily backups (as well), etc, etc, etc. For little home projects, it's > not usually worth the effort. Take your pick, where do you want to go? The two practices above – use a modern VCS, maintain TODO items such that the computer can report them automatically – are so useful and so inexpensive that I think anyone aspiring to become a good programmer is foolish if they omit them on any project. -- \ “If you make people think they're thinking, they'll love you; | `\ but if you really make them think, they'll hate you.” —Donald | _o__) Robert Perry Marquis | Ben Finney -- http://mail.python.org/mailman/listinfo/python-list
Re: Development tools and practices for Pythonistas
Am 26.04.2011 20:42, schrieb Algis Kabaila: Thomas, have you tried bzr (Bazaar) and if so do you consider hg (Mercurial) better? I have played around with bzr, but afterwards more with hg which gave me a better beeling (don't know why)... Thomas -- http://mail.python.org/mailman/listinfo/python-list
Re: Development tools and practices for Pythonistas
On Tue, Apr 26, 2011 at 11:04 AM, Jean-Michel Pichavant wrote: > You can have a look at SVN and bugzilla, they are free SCM & bug tracker > applications. > Make sure it's worth the pain though, these tools are not that easy to > administrate (the usage is pretty simple). http://trac.edgewall.org/ is purportedly pretty easy to set up - I've only used it, not set it up. Trac gives you SVN and an issue tracker. It has plugins for other source control systems. -- http://mail.python.org/mailman/listinfo/python-list
Re: Development tools and practices for Pythonistas
On Wed, Apr 27, 2011 at 12:39 AM, snorble wrote: > When I write a Python app, I have several unorganized scripts in a > directory (usually with several named test1.py, test2.py, etc., from > random ideas I have tested), and maybe a todo.txt file. ... The code is > usually out of sync with todo.txt. I see people who release new > versions and bug fixes, so I sometimes will create a new directory and > continue working from that copy, because it seems like the thing to > do. But if I ever made something worth releasing, and got a request > like, "I have problems with the 2.0 version. Can you send me the old > 1.1 version?" As other people have said, version control is very handy. I use git myself, but imho the choice of _which_ VCS you use is far less important than the choice of _whether_ to use one. As to the todo file - I tend to keep only vague ideas in a separate file. Any todo that can be logically associated with a code file or, especially, a particular piece of code, goes in that source file: def function(parms): # TODO: This should check if Foo matches Bar and shortcut the computation ... I have a very strict format: T, O, D, O, literal ASCII, always uppercase. Makes it easy to grep (and I try to avoid "todo" in lower-case, which means I can use a case-insensitive search if I choose). Additionally, if there's any task that will require checking of multiple parts of the code, I'll create a keyword for it. For instance, if I'm considering adding a local cache to an application to reduce database traffic, I might do this: //TODO CACHE: This will need to update the cache ... //TODO CACHE: Read from cache instead ... //TODO CACHE: Would this affect the cache? ... etc The benefits of having the comments right beside the code cannot be underestimated. Comments are far less likely to get out of sync if they stare you in the face while you're changing the code - this is why doxygen and friends are so useful. Ultimately, it all comes down to discipline, and how important the project is to you. At work, I have a lot of disciplines; we have a wiki where stuff gets documented, we have source control, we have daily backups (as well), etc, etc, etc. For little home projects, it's not usually worth the effort. Take your pick, where do you want to go? Chris Angelico -- http://mail.python.org/mailman/listinfo/python-list
Re: Development tools and practices for Pythonistas
On Wednesday 27 April 2011 04:31:19 CM wrote: > > I guess it depends on your project, but that sounds > > needlessly complex and way too tough with a VCS. I'd say > > just don't go there. > > (Whoops, I meant way too tough *without* a VCS, not with) And read your own emails *before* sending them :) Actually, CM has given some very good advice! As I am probably the oldest person on this list, so my penny's worth is that some going over old stuff is good - learning is repetitious and memory is not going to get better with age, so learn to live with it (it being the frailty of memory...) OldAl. -- Algis http://akabaila.pcug.org.au/StructuralAnalysis.pdf -- http://mail.python.org/mailman/listinfo/python-list
Re: Development tools and practices for Pythonistas
On Wednesday 27 April 2011 03:59:25 Thomas Rachel wrote: > Am 26.04.2011 16:39, schrieb snorble: > > When I write a Python app, I have several unorganized > I don't see how these tools will help to get up to date the > way you describe it - but all other issues are well coped > with using a VCS. I personally started with cvs (don't do > that!), then worked with svn (do that only if you really > need that), then got working with hg (Mercurial), which is a > very good thing. > > Thomas Thomas, have you tried bzr (Bazaar) and if so do you consider hg (Mercurial) better? And why is it better? (bzr is widely used in ubuntu, which is my favourite distro at present). TIA, OldAl. -- Algis http://akabaila.pcug.org.au/StructuralAnalysis.pdf -- http://mail.python.org/mailman/listinfo/python-list
Re: Development tools and practices for Pythonistas
> I guess it depends on your project, but that sounds needlessly complex > and way too tough with a VCS. I'd say just don't go there. (Whoops, I meant way too tough *without* a VCS, not with) -- http://mail.python.org/mailman/listinfo/python-list
Re: Development tools and practices for Pythonistas
On Apr 26, 10:39 am, snorble wrote: > I'm not a Pythonista, but I aspire to be. > > My current tools: > > Python, gvim, OS file system > > My current practices: > > When I write a Python app, I have several unorganized scripts in a > directory (usually with several named test1.py, test2.py, etc., from > random ideas I have tested), and maybe a todo.txt file. First, give your files meaningful names. test1.py, test2.py...no wonder you have to spend an hour just figuring out where you left off. Imagine instead if these were modules called DiskAccessUtilities.py and UserPreferencesPanel.py. You should also use highly descriptive names in naming classes and functions, too, with functions being verbs and don't be afraid of long(ish) function names like AddNewCustomerToDatabase() > Then I hack away, adding features in a semi-random order. I'd spend an hour with your TODO list and break it into priority categories, like High, Med, Low, and It Would Be Nice, and then take them strictly in that order. I'd also date the issues so you have a sense for how long something has been waiting to be fixed. > Then I get busy with other things. Maybe one week I spend 20 hours > on > development. The next week, no time on development. A few > weeks later when I have some time, I'm excited to get back to making > progress, only to find that I have to spend 30-60 minutes figuring out > where I left off. I would try to not stop in the middle of creating a new feature or fixing a bug, but try to finish it out before taking a week off. This way, when you come back, you can just tackle something from the High Priority stack and not have to figure out where you were. > The code is usually out of sync with todo.txt. That's just a matter of being disciplined. When I fix a bug, I simply cut the bug from the TODO part to the DONE part of the .txt file, nearly every time. It requires no effort compared to actually fixing the bug, yet it feels satisfying to get that text moved. > would help me to make more consistent progress, and spend less time > bringing myself up to speed after some time off. Are you documenting your code? That can help (I need to get better about that as well). Also, are things broken down into modules that are self-contained? That also can help much. Is the TODO.txt always open while you are working? It should be. Lastly, keeping some kind of notebook or even Post-Its or a bulletin board over your desk with notes as to what's next and where to hunt in your code to get at it should help. Imagine if you take two weeks off, come back, want to work on the project, and you find this note on your bulletin board: "In the CustomersPanel.py module, add support for a wxSearchCtrl (search bar) that searches the Former_Customers table in the main database..." Now you are ready to jump right in! > I really like the idea of having a list of features, and tackling > those features one at a time. I read about people who do this, and > each new features gets a new minor version number. Is that true? I'm under the impression that projects do a bunch of changes (bug fixes, and new features) and then release a new version that has a decent amount of changes. I don't think people want tons of versions of most projects around, but that each release should have an appreciable amount of good changes. > to concepts. Like, "each feature gets its own directory". I guess it depends on your project, but that sounds needlessly complex and way too tough with a VCS. I'd say just don't go there. Once you use a VCS you will probably settle into a better pattern, but things like good naming, documenting, notes, prioritizing features/ bugs, and roadmaps don't magically go away. Software development takes long range thinking and some organizational discipline. Che -- http://mail.python.org/mailman/listinfo/python-list
Re: Development tools and practices for Pythonistas
Am 26.04.2011 16:39, schrieb snorble: When I write a Python app, I have several unorganized scripts in a directory (usually with several named test1.py, test2.py, etc., from random ideas I have tested), and maybe a todo.txt file. Then I hack away, adding features in a semi-random order. Then I get busy with other things. Maybe one week I spend 20 hours on development. The next week, no time on development. A few weeks later when I have some time, I'm excited to get back to making progress, only to find that I have to spend 30-60 minutes figuring out where I left off. The code is usually out of sync with todo.txt. That happens... > I see people who release new versions and bug fixes, so I sometimes will create a new directory and continue working from that copy, because it seems like the thing to do. But if I ever made something worth releasing, and got a request like, "I have problems with the 2.0 version. Can you send me the old 1.1 version?" I'd be like, "uhhh... let me hunt through my files by hand and get back to you in a month". I'm thinking I can do a lot better than this. That is another subject (IMO), and you are right: you can do a very lot better, using the right tools. I am aware of tools like version control systems, bug trackers, and things like these, but I'm not really sure if I need them, or how to use them properly. I have been using several VCS for about 5 or 6 years now, and I can only tell you that, once started using them, you will wonder how you ever got along without them. > I think having some organization to all of this would help me to make more consistent progress, and spend less time bringing myself up to speed after some time off. I don't see how these tools will help to get up to date the way you describe it - but all other issues are well coped with using a VCS. I personally started with cvs (don't do that!), then worked with svn (do that only if you really need that), then got working with hg (Mercurial), which is a very good thing. Say, you have a certain development progress, and you add a new feature. Then you do all the changes, including increasing the version number. The changes you just have done are one changeset which you commit, providing a good commit message. If you have a version which you ship out, you give it a tag. In this way, you can easily change from 2.0 you are working on to 1.5 requested by the customer. Thomas -- http://mail.python.org/mailman/listinfo/python-list
Re: Development tools and practices for Pythonistas
snorble wrote: I'm not a Pythonista, but I aspire to be. My current tools: Python, gvim, OS file system My current practices: When I write a Python app, I have several unorganized scripts in a directory (usually with several named test1.py, test2.py, etc., from random ideas I have tested), and maybe a todo.txt file. Then I hack away, adding features in a semi-random order. Then I get busy with other things. Maybe one week I spend 20 hours on development. The next week, no time on development. A few weeks later when I have some time, I'm excited to get back to making progress, only to find that I have to spend 30-60 minutes figuring out where I left off. The code is usually out of sync with todo.txt. I see people who release new versions and bug fixes, so I sometimes will create a new directory and continue working from that copy, because it seems like the thing to do. But if I ever made something worth releasing, and got a request like, "I have problems with the 2.0 version. Can you send me the old 1.1 version?" I'd be like, "uhhh... let me hunt through my files by hand and get back to you in a month". I'm thinking I can do a lot better than this. I am aware of tools like version control systems, bug trackers, and things like these, but I'm not really sure if I need them, or how to use them properly. I think having some organization to all of this would help me to make more consistent progress, and spend less time bringing myself up to speed after some time off. I really like the idea of having a list of features, and tackling those features one at a time. I read about people who do this, and each new features gets a new minor version number. It sounds very organized and clean. But I'm not really sure of the best way to achieve this. Mainly I think I just need some recommendations to help create a good mental map of what needs to happen, and mapping jargon to concepts. Like, "each feature gets its own directory". Or with a version control tool, I don't know if a feature maps to a branch, or a commit? I appreciate any advice or guidance anyone has to offer. You can have a look at SVN and bugzilla, they are free SCM & bug tracker applications. Make sure it's worth the pain though, these tools are not that easy to administrate (the usage is pretty simple). JM -- http://mail.python.org/mailman/listinfo/python-list
Re: Development tools and practices for Pythonistas
When I said to studying two kind of Version Control. It is because I don't know if you are already working with prgramming. So I think it is very important you know how to work both ways of version control system. You don't need to install both. Just read about one and work with other. For applying changes it is better to knoow both of them. I agree with rusi in one thing. You must know one version control model, but not just distributed because some enterprise use one kind of version control system and others use another one. --- Jayme Proni Filho Skype: jaymeproni Twitter: @jaymeproni Phone: +55 - 17 - 3631 - 6576 Mobile: +55 - 17 - 9605 - 3560 e-Mail: jaymeproni at yahoo dot com dot br --- -- http://mail.python.org/mailman/listinfo/python-list
Re: Development tools and practices for Pythonistas
That's my Notebook/PC configuration and I'm user of Gentoo and Slackware. * vi (not vim) for C/C++ * Eclipse for Java * Wing IDE Professional (Python Editor); * Django: Best framework for while in my opinion; * tkinter, GTK and Qt; * MySQL, PostgreSQL ; * Rational Rose Modeler (very expensive)(UML: Because it is very important for projecting app); * Learn one CVS model and one SCM too. Enterprises use one of them; * And you must STUDY, READ AND READ, READ every official docs about these stuffs. About your project's tree, I can not help you because you wil get this with time and CVS and SCM help you to learn about trees. Now, about tree in the beginning, when I started in 1993, I used to do like this way. Primary folder called: pythoncourse Sub folders calld: for, if, while, do_while, array, list, hash, functions, pydb, publish, comments, iterative, recursion and etc. My archives I called: In sub-folder FOR: for1.py, for2.py, for_in_for.py for_final.py, for example. My English use to be better than this but I'm starving here writing for you and thinking and so much stakes. Bye bye. :D Good studies and ideas. --- Jayme Proni Filho Skype: jaymeproni Twitter: @jaymeproni Phone: +55 - 17 - 3631 - 6576 Mobile: +55 - 17 - 9605 - 3560 e-Mail: jaymeproni at yahoo dot com dot br --- -- http://mail.python.org/mailman/listinfo/python-list
Re: Development tools and practices for Pythonistas
On 26/04/2011 14:39, snorble wrote: I would strongly advice to get familiar with: - Lint tools (like PyLint) - Refactoring - Source Control Systems (like Mercurial Hg) - Unit Testing with Code Coverage Followed by either writing your own toolset that integrates all of the above or start learning an IDE that has that stuff built-in (my personal preference is the latter with my current IDE being PyDev (Eclipse)). Yes you will be less productive for a couple of weeks, but I promise you that once you know the above you win that time back very shortly, or if you are as chaotic as me, within a week :-). -- mph -- http://mail.python.org/mailman/listinfo/python-list
Re: Development tools and practices for Pythonistas
On Apr 26, 7:39 pm, snorble wrote: > I am aware of tools like version control systems, bug trackers, and > things like these, but I'm not really sure if I need them, You either dont want version control > But if I ever made something worth releasing, and got a request > like, "I have problems with the 2.0 version. Can you send me the old > 1.1 version?" I'd be like, "uhhh... let me hunt through my files by > hand and get back to you in a month". I'm thinking I can do a lot > better than this. Or you do! > or how to use them properly. So the best advice would be: Forget python (for a while) and study one (modern distributed) version control system: http://en.wikipedia.org/wiki/Distributed_revision_control >From Joel Spolsky's http://joelonsoftware.com/items/2010/03/17.html With distributed version control, the distributed part is actually not the most interesting part. The interesting part is that these systems think in terms of changes, not in terms of versions. bug-trackers are a bit of overkill for a solo developer. However... > My current tools: > Python, gvim, OS file system Hand in hand with a DVCS, you need to add a testing framework. -- http://mail.python.org/mailman/listinfo/python-list
Development tools and practices for Pythonistas
I'm not a Pythonista, but I aspire to be. My current tools: Python, gvim, OS file system My current practices: When I write a Python app, I have several unorganized scripts in a directory (usually with several named test1.py, test2.py, etc., from random ideas I have tested), and maybe a todo.txt file. Then I hack away, adding features in a semi-random order. Then I get busy with other things. Maybe one week I spend 20 hours on development. The next week, no time on development. A few weeks later when I have some time, I'm excited to get back to making progress, only to find that I have to spend 30-60 minutes figuring out where I left off. The code is usually out of sync with todo.txt. I see people who release new versions and bug fixes, so I sometimes will create a new directory and continue working from that copy, because it seems like the thing to do. But if I ever made something worth releasing, and got a request like, "I have problems with the 2.0 version. Can you send me the old 1.1 version?" I'd be like, "uhhh... let me hunt through my files by hand and get back to you in a month". I'm thinking I can do a lot better than this. I am aware of tools like version control systems, bug trackers, and things like these, but I'm not really sure if I need them, or how to use them properly. I think having some organization to all of this would help me to make more consistent progress, and spend less time bringing myself up to speed after some time off. I really like the idea of having a list of features, and tackling those features one at a time. I read about people who do this, and each new features gets a new minor version number. It sounds very organized and clean. But I'm not really sure of the best way to achieve this. Mainly I think I just need some recommendations to help create a good mental map of what needs to happen, and mapping jargon to concepts. Like, "each feature gets its own directory". Or with a version control tool, I don't know if a feature maps to a branch, or a commit? I appreciate any advice or guidance anyone has to offer. -- http://mail.python.org/mailman/listinfo/python-list
