add Optparse UI interaction

[pierre-haessig]

This is a follow-up of issue #8 about getopt implementation by djmitche.

The purpose is the same : "making pyflakes a little friendlier".
Only I used optparse, because I feel it's nicer ;-)

Notice : I screwed my master branch by adding an unrelated commit about adding a README file. I didn't manage to rebase the patch correctly... I'll glad to learn how to put things right.

(this README file could be actually another pull request...)

[djmitche]

You can fix the repo as follows:

git checkout -b readme optparse^
git checkout optparse
git rebase -i master
# delete the README line (it was saved in the readme branch, above)
git push # to whatever remote points to your github account

the pull request will update automatically to reflect the change.

350a04f looks good to me

[pierre-haessig]

Thanks for the help !
(I actually had to rebase on master^ because my master branch was already "polluted" by the README commit. Also, I had to force the push, but I guess there was no other choice)

[djmitche]

+1 here - kevin, want to merge?

[pierre-haessig]

I friend made me notice that kevin's branch is lagging.
From https://github.com/kevinw/pyflakes/network I discovered there has been a lot of commits, from dcramer and RonnyPfannschmidt for instance.
In some of these versions, optparse frontend has been already implemented (to exclude some files). Also unittests have been added which is great. And another guy, Wilfred, just added a readme. This development is great and alive, but it's so messy !

[djmitche]

Indeed, and a number of open pull requests here. I emailed Kevin to see if he wants help with the project. Maybe we should set up a pyflakes organization and start merging contributions there?

This is the fun of DVCS's - project forks are easy when upstream goes away - and it just takes someone standing up to bring them back together.

[djmitche]

In fact, I just created such an organization and repository - https://github.com/pyflakes/pyflakes. I'll merge this pull request there, and see what else I can find.

[djmitche]

OK, there appears to be a 0.5.0 release out on launchpad and pypi, which this version doesn't incorporate. Let's hope we can concentrate everything on the github org, or shut it down and concentrate on launchpad? Although I can't find the code on launchpad, so .. I don't know.

[Daenyth]

I'd really suggest centralizing on github.

[kisielk]

The code on launchpad is maintained by the divmod group (#divmod on freenode.org). Should check with them before trying to move anything.

[djmitche]

Yes, and I'm sorry for stirring up a mess. The problem is that this version is a pretty significant fork, so even setting VC issues aside, it's not that easy to merge them.

[kisielk]

I'm not really sure what's so significantly different about this fork versus the official divmod version any more. The recent changes in the official divmod repo also modified pyflakes to use the ast module. I've been using the official version for the last few weeks and have yet to see any deviation in behaviour from when I was using this fork.

[djmitche]

Then perhaps we should close this fork? @kevinw, what do you think?

[jjmaestro]

+1 but I would try to talk the divmod team into moving the repo to GH. I mean... Launchpad is as crappy and cryptic as it can be, really hard to contribute anything (and sometimes even report bugs!).

[saper]

-1 from me for this change... There is no need for any options right now really (there are some forks floating around to turn off some warnings, but frankly I believe most of them are caused by issue #13).

[pierre-haessig]

This old PR is almost surely no longer relevant.