On Mon, Jun 10, 2013 at 2:21 PM, Alan Cabrera <[email protected]> wrote: > > On Jun 10, 2013, at 10:30 AM, Greg Stein <[email protected]> wrote: >... >> 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?
I have no idea. We have none. IOW, I would say bin/ isn't needed right now. We have nothing to put into it (assuming the continued use of cmdline/). > 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? Apache Steve will install two sets of things: * a set of command-line tools * a web-based interface to those tools cmdline/ is the first batch, and www/ is the second. We have some stuff under monitoring/ that needs to be shifted around. And some other miscellaneous files to get organized. >>>>> 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? "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. How many of those will we need? We have about 2000 lines of script. Much of that is actually boilerplate text or html. Do we need "plugin support" in our unit tests? Or do we need things like: assert "[email protected]" in voters ? My concern is that some of these dependencies are what I'd see for a large, complicated system. Apache Steve isn't that. I don't even see how/where it would go into something like that. >... >> 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? "All" is just steve.py. 156 lines. We could have src/steve.py. I didn't think that we would have any other source, so I put it into lib/, much like Python modules are installed into /usr/lib or /usr/local/lib or .... So again: I'm not presupposing anything, and I just put it into lib/. We can always rearrange if/when we find things get more complicated. >... > Do we really have to have .py at the end of our command line tools? (yuck) > :) Sigh. Look at cmdline/, please. All the scripts end in .pl. The Makefile builds equivalents based on wrapsuid.c that omit the suffix. The *real* invocation (which uses setuid) will not have the suffix. The module can/should so that we can import the module for testing, or for other needs. Cheers, -g
