On Jun 10, 2013, at 10:30 AM, Greg Stein <gst...@gmail.com> wrote: > On Mon, Jun 10, 2013 at 9:41 AM, Alan Cabrera <l...@toolazydogs.com> wrote: >> On Jun 9, 2013, at 9:40 PM, Greg Stein <gst...@gmail.com> wrote: >> ... >>>> Added: >>>> steve/trunk/bin/ >>>> steve/trunk/bin/votegroup (with props) >>> >>> The existing structure puts all the cmdline tools under cmdline/. I >>> think that makes more sense, as it delineates what scripts are part of >>> the Apache Steve command-line tools. (as opposed to others scripts >>> used within/by the project) >> >> I'm just following the convention that other Python projects, e.g. boto, and >> we, at my work, use. >> >> With that said, what other scripts are we talking about? > > Look in cmdline! There are six cmdline tools. We probably need to > shift some of the monitoring tools in there, too. > > I don't know what would go into bin/.
The scripts that are in cmdline seem to be six Apache Steve cmdline tools. You mention "other scripts used within/by the project". What are those scripts? With that said, bin/ seems to be the Python standard to put command line tools; I use boto as an example. Is this not the case? >>>> steve/trunk/requirements.txt >>> >>> Is the unittest framework missing something that we require? Why >>> 'nose' rather than plain unit test? >> >> I love nose. > > What does it provide that we'll need? Advantages: You can write test functions, and not forced to write test classes. Automatic tests discovery and collecting, you do not have to build test suites manually. Plugin support Very useful standard plugins (coverage, output capture, drop into debugger on errors, doctests support, profiler) Test tagging and easy selection of test sets based on tags. Parallel testing Flexible fixtures support Test generators It could very well be that plain unit test supports the above and it's my ignorance that has led me to my opinions. >>>> steve/trunk/setup.cfg >>>> steve/trunk/setup.py (with props) >>>> steve/trunk/src/ >>>> steve/trunk/src/steve/ >>>> steve/trunk/src/steve/__init__.py >>>> steve/trunk/src/steve/voters.py >>> >>> When I ported our steve.pm module, I just put them all into one single >>> module. In fact, Jim already collected several modules to incorporate >>> them into that steve.pm. I see no reason to break them out into a >>> package. That is overly-complicated -- steve.py is 157 lines and a >>> dozen simple functions. I don't envision it to grow by much, as Steve >>> has existed in this form for a good while. >> >> I, and I think Matt, have a larger vision. I foresee the package becoming a >> junk drawer very soon. But I do agree, you've caught pre-mature packaging >> there. >> >> With that said, do you agree that your code in lib should move to >> steve/trunk/src/steve/__init__.py? > > Nope. It isn't a package' it's just a simple library module. It is a > dozen small helper functions. > > Unless/until that dramatically grows (towards what?), then I think we > should choose simple. I'm sure that I'm being dense. How does that answer my question about moving your code to steve/trunk/src/steve/__init__.py? Should we not put all our library code in steve/trunk/src/steve? >> ... >>> And the last bit for this review is your @entrypoint decorator. It >>> doesn't do what most people would expect. In many cases, I might write >>> a script like this: >>> >>> #/usr/bin/python >>> #... >>> >>> def main(...): >>> # do something >>> >>> class Support(...) >>> # whatever >>> >>> def helper_func(...): >>> # something >>> >>> class MyException(...): >>> # whatever >>> >>> if __name__ == '__main__': >>> main(...) >> >> It's a shell script. Why bother with the above conditional? Just wondering. > > Well... with a .py extension (like we've done in cmdline/*.pl), then > it is also an importable module. As you know, that's the whole reason > for the __name__ construct: to differentiate between invocation and > importing. As a result, you may want to structure/order the file > differently if you're building a dual-purpose module. (eg. self-test > if run as a script, but normally be a module) Sounds like mixing concerns, but I won't belabor the issue. Do we really have to have .py at the end of our command line tools? (yuck) :) Regards, Alan
