I've released three ratchets' project today.
projectinfo
==========
This is the ProjectInfo class (which was born from reap) it's doesn't
do anything on it's own. It's a support library for providing
encapsulation of project information --it's quite extensive however,
and somewhat unique in functionality. Also it can load up from a YAML
configuration simply by
ProjectInfo.load
As long as your somewhere down in your project directory this will
find it and load it up. (FYI, for the moment you have to create
ProjectInfo files by hand. To make it easier just copy the one from
projectinfo itself and edit to suit your needs.)
exacto
======
This is a independent tool for extracting code from comments.
Presently is only support =begin {handle}...=end comments, though I
plan to make it more capable in the future. handle defaults to "test",
which makes it a cinch to run embedded tests. Use it like this:
$ exacto myfile.rb | ruby
It also incudes a shortcut for the above called 'exrb'
$ exrb myfile.rb
autorake
========
This is main part of rathcets i've been working on. i decided to scale
back a little and use rake as the task execution system (in the future
I may split out the internal Project class (as reap?) that does all
the work, but there sill some details to address with that). if you
used reap in the past then you essentially know how to use autorake
except it's more polished now. quick example:
~/ruby/autorake$ rake -T
(in /file/trans/my/code/ruby/ratchets/src/autorake)
AutoRake 0.4 beta
rake announce # Make a release announcement
rake changelog # Produce changelog (None)
rake check # Rundown checklist
rake diff # Verify the manifest
rake install # Local setup & install
rake loads # Test loadpath dependencies
rake manifest # Generate package manifest
rake notes # Compile developer notes
rake pack # Build all packages
rake prepare # Full preperations cycle
rake publish # Publish website (Rubyforge)
rake rdocs # Generate local rdocs
rake release # Release packages (Rubyforge)
rake ridocs # Generate local ri docs
rake stats # Code count analysis
rake syntax # Run syntax check
rake test # Run isolated unit test
rake tests # Extract embedded tests
rake version # Calculate version (None)
All you need is a ProjectInfo file in you project's root dir, and a
Rakefile that starts with:
require 'autorake'
Couple of quick notes b/c I haven't done docs yet. The (None) you see
means there is no SCM being used. If I were using Darcs for the
AutoRake project it would say (Darcs) and could generate a version
stamp and a changelog automatically via 'darcs' (file names default to
VERSION and CHANGES). Subversion is not yet supported but that's next
on the todo list (would any would like to make the adapter? :-) rdocs
and ridocs, by default are stored in doc/rdoc and doc/ri,
respectively. notes generate TODO and FIXME files in doc/ as well. The
check task runs diff, syntax, loads and test, in that order; prepare
runs changelog, version, manifest and then pack. Currently I'm using
Rake's packaging system which is a little messy (IMHO) but it works
well enough. Also, at the moment, only Rubyforge publishing and
releasing is supported. On the todo list are generic versions of each.
The only other major things it doesn't yet support is clean/clobber.
This isn't a problem for pure ruby projects b/c internally it uses an
"ignore" configuration parameter to only include the appropriate files
in the manifest and the package. but clean/clobber is on the todo
list.
Being initial public releases of course there will arise some issue,
please let me know what you encounter so I can fix asap. Note these
have only been tested on Linux. Also, always good advice: be safe and
backup up your projects from time to time.
T.
P.S. Facets is of course is required ;-)
_______________________________________________
Nitro-general mailing list
Nitro-...@rubyforge.org
http://rubyforge.org/mailman/listinfo/nitro-general
> and thanks for your great work. I am wondering if you could help the Nitro
> project and provide soem autorake files for Nitro and Og. Epscially this
> rake publish thing would be nice to have!
oh yes yes, a Rakefile, to also let these tests run on Firebrigade:
http://firebrigade.seattlerb.org/build/show/12012
This I guess only looks that way, because it doesn't know how to run our
tests. With a Rakefile that won't be a problem anymore.
Only thing with Rake tests is, that it runs them in a single 'run', where
some tests interfere with one another. A while back I minimized those
interferances, but I think some are still there.
Jo
--
Feel the love
http://pinkjuice.com/pics/ruby.png
On Feb 10, 4:56 am, "Jonathan Buch" <j...@oxyliquit.de> wrote:
> Hi,
>
> > and thanks for your great work. I am wondering if you could help the Nitro
> > project and provide soem autorake files for Nitro and Og. Epscially this
> > rake publish thing would be nice to have!
>
> oh yes yes, a Rakefile, to also let these tests run on Firebrigade:
>
> http://firebrigade.seattlerb.org/build/show/12012
>
> This I guess only looks that way, because it doesn't know how to run our
> tests. With a Rakefile that won't be a problem anymore.
>
> Only thing with Rake tests is, that it runs them in a single 'run', where
> some tests interfere with one another. A while back I minimized those
> interferances, but I think some are still there.
If Firebrigade can run the test task as defined by our Rakefile that
won't be a problem. autorake's test task runs each test as a separate
proccess.
(You see, I've had this problem before too ;-)
T.
>
>
> On Feb 10, 4:56 am, "Jonathan Buch" <j...@oxyliquit.de> wrote:
>> Hi,
>>
>> > and thanks for your great work. I am wondering if you could help the
>> Nitro
>> > project and provide soem autorake files for Nitro and Og. Epscially
>> this
>> > rake publish thing would be nice to have!
>>
>> oh yes yes, a Rakefile, to also let these tests run on Firebrigade:
>>
>> http://firebrigade.seattlerb.org/build/show/12012
>>
>> This I guess only looks that way, because it doesn't know how to run our
>> tests. With a Rakefile that won't be a problem anymore.
>>
>> Only thing with Rake tests is, that it runs them in a single 'run',
>> where
>> some tests interfere with one another. A while back I minimized those
>> interferances, but I think some are still there.
>
> If Firebrigade can run the test task as defined by our Rakefile that
> won't be a problem. autorake's test task runs each test as a separate
> proccess.
> (You see, I've had this problem before too ;-)
>
Speaking of which... is there any work done already for integration with
RSpec and or Rcov?
Anyway, great work!
Will try it immediatly :)
^ manveru
>
>
> On Feb 10, 4:56 am, "Jonathan Buch" <j...@oxyliquit.de> wrote:
>> Hi,
>>
>> > and thanks for your great work. I am wondering if you could help the
>> Nitro
>> > project and provide soem autorake files for Nitro and Og. Epscially
>> this
>> > rake publish thing would be nice to have!
>>
>> oh yes yes, a Rakefile, to also let these tests run on Firebrigade:
>>
>> http://firebrigade.seattlerb.org/build/show/12012
>>
>> This I guess only looks that way, because it doesn't know how to run our
>> tests. With a Rakefile that won't be a problem anymore.
>>
>> Only thing with Rake tests is, that it runs them in a single 'run',
>> where
>> some tests interfere with one another. A while back I minimized those
>> interferances, but I think some are still there.
>
> If Firebrigade can run the test task as defined by our Rakefile that
> won't be a problem. autorake's test task runs each test as a separate
> proccess.
> (You see, I've had this problem before too ;-)
Ok, after trying it... a couple of questions :)
- I need a way to say my tests are in spec/tc_*
- The MANIFEST lists all files, i got some non-ruby files as well, for
which ruby -c fails, is there a way to only let it run over .rb files?
- How exactly do autorake and ProjectInfo cooperate? does autorake use my
ProjectInfo automagically?
Maybe some more questions later... gotta go...
All in all it seems like a really nice rake that finally understands it's
not only about tasks but about tasks for a specific project, i find that
very positive :)
And thanks for all the fish.
^ manveru
On Feb 15, 3:48 am, "Michael Fellinger" <manv...@weez-int.com> wrote:
> Ok, after trying it... a couple of questions :)
>
> - I need a way to say my tests are in spec/tc_*
In ProjectInfo you can use
tests: spec/tc_*.rb
or
test_files: spec/tc_*.rb
or
test:
files: spec/tc_*.rb
these should all be synonomous. also note, that i put the .rb on there
just as an extra precaution --it's not required, and also you can
specifiy more than one glob in an array if you need it. For example:
test:
files:
- test/tc_*.rb
- spec/tc_*.rb
> - The MANIFEST lists all files, i got some non-ruby files as well, for
> which ruby -c fails, is there a way to only let it run over .rb files?
The manifest or syntax task? If syntax, you should be able to set
scripts: lib/**/*.rb
I just fixed a bug and that will now be the default in >0.5.2, but I'm
not 100% about the name of that setting yet. But if you mean the
manifest that's defined by
distribute: **/*
Since the intent of the manifest is to list all files that will be
included in the distributed package, by default that includes
everything minus "project.ignore" which contains typical exclusions
(like _darcs). You can set distribute straight (though ignore is
always excluded) or you can easily adjust it with a '-' prefix too.
For example I often have a scrap directory to store old code that I'm
not quite ready to throw away. So I have:
distribute: [ -scrap ] # yes, this can be an array too
it's a recursive glob btw, so everything within scrap/ is excluded.
> - How exactly do autorake and ProjectInfo cooperate? does autorake use my
> ProjectInfo automagically?
Essentially yes. In autorake there's a Project class that delegates to
ProjectInfo via #info. Then all the actual tasks are defined as
methods of Project and each snags information from #info as needed. I
had planned to define the task and the code that pulls the info it
needs separately, but I let that SOC go for now. The ProjectIndfo
class itself makes things easier by offering defaults and also by the
way it loads. An entry like:
test:
files: **/test*.rb
actually maps to ProjectInfo#test_files.
> Maybe some more questions later... gotta go...
> All in all it seems like a really nice rake that finally understands it's
> not only about tasks but about tasks for a specific project, i find that
> very positive :)
That's it exactly, well put. And I am very glad to hear it. Let me
know if you have any other troubles or suggestions. I just fixed a
couple bugs and uploaded 0.5.1.
> And thanks for all the fish.
All 42 ;) Whew, it's late and I'm very tired. Nite.
HTH,