From zdavatz at gmail.com Fri Feb 11 10:52:26 2011 From: zdavatz at gmail.com (Zeno Davatz) Date: Fri, 11 Feb 2011 16:52:26 +0100 Subject: [Rake-devel] rake check_manifest deletes my doc Directory Message-ID: Hi I am using rake for a lot of our web projects. Those project all have a _doc_ directory. Now if I go by the books and run rake check_manifest my doc directory is wiped away. That is sad and not so userfriendly. Any hints how I could prevent that? Thank you for your Feedback. Best Zeno From Torsten at robitzki.de Sun Feb 20 07:19:22 2011 From: Torsten at robitzki.de (Torsten@Robitzki.de) Date: Sun, 20 Feb 2011 13:19:22 +0100 Subject: [Rake-devel] Parameter not task key? Message-ID: <71E205BF-B0A1-4597-AC9E-372C05EBE045@robitzki.de> Hello, I'm currently trying to build an existing C++ project with rake. I want to build different "flavors" (debug, release, etc.) of the software. Every flavor uses it's own output directory, so the different flavors can live in parallel. To pass the flavor to rake, I use the task parameter. The tasks are build automatically from the existing source directory structure. What puzzled me a little bit is, that the parameter isn't part of the key (or name) of a task. When I try to build two different flavors of the same task, the task gets executed once, not twice as I've thought it should be. Example: rake libs[debug] libs[release] Is this intended behavior or should I fill a bug-report / feature-request? best regards Torsten btw: Thanks for the wonderful tool (rake) From JUP at ramboll.com Tue Feb 22 03:39:17 2011 From: JUP at ramboll.com (Jesper Tholstrup Pedersen (JUP)) Date: Tue, 22 Feb 2011 09:39:17 +0100 Subject: [Rake-devel] Task for nested instance of Rake Message-ID: <5B450D9A3AEFEE4CA1DA21A968DF6C3A0227CA98@dkgrouprogex33.ramboll-group.global.network> Hi. I'm a .NET developer. I recently decided to use Rake to handle things such as deployment and database management for my .NET projects. The projects are still build using MSBuild cause of Visual Studio (VS). One problem I continually encounter is that there is no natural way to order dependent projects using Rake. I'll give an example: In .NET it is quite natural to order projects in a nested structure with a master project that have a number of sub-projects in a hierarchical structure (as shown below). C:\Projects\Project1\master vs file C:\Projects\Project1\Rakefile.rb C:\Projects\Project1\... (master project files) C:\Projects\Project1\SubProject1\sub1 vs file C:\Projects\Project1\SubProject1\Rakefile.rb C:\Projects\Project1\SubProject1\... (sub1 project files) C:\Projects\Project1\SubProject2\sub 2 vs file C:\Projects\Project1\SubProject2\Rakefile.rb C:\Projects\Project1\SubProject2\... (sub2 project files) ... Now if you for any reason have an interest in separating the sub-projects from the master in VS, you would still order the files and folders in a hierarchy since there is a dependency. By separating the individual sub-projects from the master you no longer have the option to say run all tests in all projects, this is where Rake becomes interesting. The rakefile for each sub-project are quite easy to create and maintain since they individually are isolated, the problem is when we get to the master rakefile. I want to stress the point that the sub-projects rakefiles are completely isolated meaning that they are not and should not be aware of the master rakefile. I have not been able to find a satisfactory solution where the master rakefile can call each sub-projects rakefile. In other build management solutions like Ant, NAnt and MSBuild there is a task that can run a nested instance on a specified build file. There appears to be some half-baked solutions for this with Rake: 1. Run a rake command for each sub-projects rakefile on the system as a command line. 2. Import the tasks in each sub-projects rakefile and run them. The number 1 solution has a few problems: 1. Propagating the initial Rake options (e.g. --trace) must be performed manually. 2. A failed sub-project build will not stop the master from calling the next sub-project. The number 2 solution has the problem that the sub-projects rakefile is dependent on all other rakefiles in the project since there must not be any task name clashes. This is unacceptable since you would no longer have the ability to run a sub-projects rakefile with the standard assumptions (like running "rake test" on a subproject). Adding a "Rake task" which enables Rake to run a nested instance would be the perfect solution for me, I just don't have that much experience with Ruby yet to be able to develop it myself. So the real question is: does anybody have this need? And would somebody with the Ruby experience like to create this task? /Jesper From Torsten at Robitzki.de Tue Feb 22 04:10:18 2011 From: Torsten at Robitzki.de (Torsten at Robitzki.de) Date: Tue, 22 Feb 2011 10:10:18 +0100 Subject: [Rake-devel] Task for nested instance of Rake In-Reply-To: <5B450D9A3AEFEE4CA1DA21A968DF6C3A0227CA98@dkgrouprogex33.ramboll-group.global.network> References: <5B450D9A3AEFEE4CA1DA21A968DF6C3A0227CA98@dkgrouprogex33.ramboll-group.global.network> Message-ID: <80D57C4E-C04C-4045-A0E1-2881949DA71C@Robitzki.de> Hello Jasper, > The number 2 solution has the problem that the sub-projects rakefile is > dependent on all other rakefiles in the project since there must not be > any task name clashes. This is unacceptable since you would no longer > have the ability to run a sub-projects rakefile with the standard > assumptions (like running "rake test" on a subproject). maybe you could use namespaces around your sub-rakefiles. best regards Torsten From JUP at ramboll.com Wed Feb 23 03:50:08 2011 From: JUP at ramboll.com (Jesper Tholstrup Pedersen (JUP)) Date: Wed, 23 Feb 2011 09:50:08 +0100 Subject: [Rake-devel] Task for nested instance of Rake Message-ID: <5B450D9A3AEFEE4CA1DA21A968DF6C3A0227CC86@dkgrouprogex33.ramboll-group.global.network> Hi Torsten, > maybe you could use namespaces around your sub-rakefiles. Do you mean to say that I can import a sub-rakefile into a certain namespace without altering the sub-rakefile? If so how would you go about doing that? /Jesper From JUP at ramboll.com Wed Feb 23 04:52:18 2011 From: JUP at ramboll.com (Jesper Tholstrup Pedersen (JUP)) Date: Wed, 23 Feb 2011 10:52:18 +0100 Subject: [Rake-devel] Task for nested instance of Rake In-Reply-To: <5B450D9A3AEFEE4CA1DA21A968DF6C3A0227CC86@dkgrouprogex33.ramboll-group.global.network> References: <5B450D9A3AEFEE4CA1DA21A968DF6C3A0227CC86@dkgrouprogex33.ramboll-group.global.network> Message-ID: <5B450D9A3AEFEE4CA1DA21A968DF6C3A0227CCC2@dkgrouprogex33.ramboll-group.global.network> Hi. I have been trying the following: A master file in ex: C:\Master\Rakefile.rb ... with the contents: require "rake" task :default => [:master_build] ns = namespace "sub1" do puts "Importing sub1." import Dir.pwd + "/Sub1/Rakefile.rb" puts "sub1 imported." end task :master_build => [:build_dependencies] do puts "task :master_build run." end task :build_dependencies do #Add ns["build"] as prerequisite puts "task :build_dependencies run." End And a sub-project in ex: C:\Master\Sub1\Rakefile.rb ... with the contents: require "rake" task :default => [:build] task :build do puts "task :build run." puts "Current directory: #{Dir.pwd}" end Now initially what goes wrong is that the task :default contains 2 prerequisites after the Sub1\Rakefile.rb is loaded. The result is that invoking the :default task of the master also invokes the :default task of the sub. Second the Sub1\Rakefile.rb should be run in its own context i.e. with Dir.pwd set to C:\Master\Sub1\ Was this what you had in mind Torsten? /Jesper From Torsten at Robitzki.de Wed Feb 23 05:07:29 2011 From: Torsten at Robitzki.de (Torsten at Robitzki.de) Date: Wed, 23 Feb 2011 11:07:29 +0100 Subject: [Rake-devel] Task for nested instance of Rake In-Reply-To: <5B450D9A3AEFEE4CA1DA21A968DF6C3A0227CC86@dkgrouprogex33.ramboll-group.global.network> References: <5B450D9A3AEFEE4CA1DA21A968DF6C3A0227CC86@dkgrouprogex33.ramboll-group.global.network> Message-ID: <6EBF2F54-94C3-4764-B35B-573D1E50C763@Robitzki.de> Am 23.02.2011 um 09:50 schrieb Jesper Tholstrup Pedersen (JUP): > Do you mean to say that I can import a sub-rakefile into a certain > namespace without altering the sub-rakefile? > I think so. I haven't worked with namespaces but what I've read from the documentation, they might help you, solving your problems: http://rake.rubyforge.org/files/doc/rakefile_rdoc.html (search for namespace on that page). > If so how would you go about doing that? I would try: namespace "SubProject1" load "./SubProject1/Rakefile.rb" end best regards Torsten From Torsten at Robitzki.de Wed Feb 23 05:46:33 2011 From: Torsten at Robitzki.de (Torsten at Robitzki.de) Date: Wed, 23 Feb 2011 11:46:33 +0100 Subject: [Rake-devel] Task for nested instance of Rake In-Reply-To: <5B450D9A3AEFEE4CA1DA21A968DF6C3A0227CCC2@dkgrouprogex33.ramboll-group.global.network> References: <5B450D9A3AEFEE4CA1DA21A968DF6C3A0227CC86@dkgrouprogex33.ramboll-group.global.network> <5B450D9A3AEFEE4CA1DA21A968DF6C3A0227CCC2@dkgrouprogex33.ramboll-group.global.network> Message-ID: Am 23.02.2011 um 10:52 schrieb Jesper Tholstrup Pedersen (JUP): > Now initially what goes wrong is that the task :default contains 2 > prerequisites after the Sub1\Rakefile.rb is loaded. The result is that > invoking the :default task of the master also invokes the :default task > of the sub. I would expect this to happen, as the sub project is usually a part of the master project. Or you just want to have a different default task, depending on the file that was invoked? If so, what comes to mine mind is to use some kind of flag used to conditional add the sub tasks to the default task. Or maybe there is a way to extract the namespace, so that sub projects would add there dependencies only to the default task, if they are in the global namespace. > Was this what you had in mind Torsten Yes, something like this. I wouldn't have added the subprojects in a task, but simply unconditional, while loading the rakefile. best regards Torsten From JUP at ramboll.com Wed Feb 23 06:59:53 2011 From: JUP at ramboll.com (Jesper Tholstrup Pedersen (JUP)) Date: Wed, 23 Feb 2011 12:59:53 +0100 Subject: [Rake-devel] Task for nested instance of Rake In-Reply-To: References: <5B450D9A3AEFEE4CA1DA21A968DF6C3A0227CC86@dkgrouprogex33.ramboll-group.global.network><5B450D9A3AEFEE4CA1DA21A968DF6C3A0227CCC2@dkgrouprogex33.ramboll-group.global.network> Message-ID: <5B450D9A3AEFEE4CA1DA21A968DF6C3A0227CD35@dkgrouprogex33.ramboll-group.global.network> > I would try: > > namespace "SubProject1" > load "./SubProject1/Rakefile.rb" > end That worked perfectly... Changing the import statement to load solved the first part of my problem. The second part is making the loaded rakefile run from the correct sub directory. At the moment I have encapsulated this in a task. If you have any suggestions as to how the this could be packaged as a new task flavor, I'm all ears. My solution so far looks like this: -- Master-rakefile -- require "rake" task :default => [:master_build] task :master_build => [:build_dependencies] do puts "task :master_build run." end task :build_dependencies => [:build_sub1] do puts "task :build_dependencies run." end @sub1_directory = Dir.pwd + "/Sub1" namespace "sub1" do puts "Importing sub1." load "#{@sub1_directory}/Rakefile.rb" puts "sub1 imported." end task :build_sub1 do current_directory = Dir.pwd Dir.chdir "#{@sub1_directory}" Rake::Task["sub1:build"].invoke Dir.chdir "#{current_directory}" end -- sub-rakefile -- require "rake" task :default => [:build] task :build do puts "task :build run." puts "Current directory: #{Dir.pwd}" end >> Now initially what goes wrong is that the task :default contains 2 >> prerequisites after the Sub1\Rakefile.rb is loaded. The result is that >> invoking the :default task of the master also invokes the :default >> task of the sub. > I would expect this to happen, as the sub project is usually a part of the master project. Yes, that does require some explanation: The short answer is that a sub-project at times are part of more than one master project. The long answer is that in the interest of continues integration I want dependent libraries and frameworks built and tested every time a release is underway. This is why it is so important that the sub-projects are independent of the master, they must be able to be a sub-project in several projects. In essence the sub-project is not owned by the master project in this setting. By the way, thank you for your help so far. /Jesper From Torsten at Robitzki.de Thu Feb 24 03:01:21 2011 From: Torsten at Robitzki.de (Torsten at Robitzki.de) Date: Thu, 24 Feb 2011 09:01:21 +0100 Subject: [Rake-devel] Task for nested instance of Rake In-Reply-To: <5B450D9A3AEFEE4CA1DA21A968DF6C3A0227CD35@dkgrouprogex33.ramboll-group.global.network> References: <5B450D9A3AEFEE4CA1DA21A968DF6C3A0227CC86@dkgrouprogex33.ramboll-group.global.network><5B450D9A3AEFEE4CA1DA21A968DF6C3A0227CCC2@dkgrouprogex33.ramboll-group.global.network> <5B450D9A3AEFEE4CA1DA21A968DF6C3A0227CD35@dkgrouprogex33.ramboll-group.global.network> Message-ID: Hello Jesper Am 23.02.2011 um 12:59 schrieb Jesper Tholstrup Pedersen (JUP): > The second part is making the loaded rakefile run from the correct sub > directory. > At the moment I have encapsulated this in a task. > > If you have any suggestions as to how the this could be packaged as a > new task flavor, I'm all ears. > From what I've found: __FILE__ seems to be the currently executed Ruby script, so passing __FILE__ to the following function should yield in changing to the current ruby/rake script. def set_current_directory source_file Dir.chdir File.dirname(source_file) end def task_from_current_directory source_file, *args, &block define_task(args) { set_current_directory source_file } define_task(args, block) // maybe it's worth thinking about setting the current directory back again here end Usage: task_from_current_directory __FILE__, :build do puts "task :build run." puts "Current directory: #{Dir.pwd}" end This is not tested, but I hope one can get the idea. I don't know how and when default arguments are added to a function call in ruby. Maybe it is possible to pass the __FILE__ as a default parameter. best regards Torsten From JUP at ramboll.com Fri Feb 25 03:00:28 2011 From: JUP at ramboll.com (Jesper Tholstrup Pedersen (JUP)) Date: Fri, 25 Feb 2011 09:00:28 +0100 Subject: [Rake-devel] Task for nested instance of Rake In-Reply-To: References: <5B450D9A3AEFEE4CA1DA21A968DF6C3A0227CC86@dkgrouprogex33.ramboll-group.global.network><5B450D9A3AEFEE4CA1DA21A968DF6C3A0227CCC2@dkgrouprogex33.ramboll-group.global.network><5B450D9A3AEFEE4CA1DA21A968DF6C3A0227CD35@dkgrouprogex33.ramboll-group.global.network> Message-ID: <5B450D9A3AEFEE4CA1DA21A968DF6C3A0227D098@dkgrouprogex33.ramboll-group.global.network> Thank you for your help Torsten. To the maintainers and contributors of Rake: Thank you for spending your time on making the lives of developers easier with this tool. It is most appreciated. /Jesper From quixoticsycophant at gmail.com Sun Feb 27 23:10:02 2011 From: quixoticsycophant at gmail.com (James M. Lawrence) Date: Sun, 27 Feb 2011 23:10:02 -0500 Subject: [Rake-devel] About that new magic comment ... Message-ID: Assume the following tasks were written for Rake 0.8.x. # This comment describes a non-toplevel-task. task :complex_task do # ... end # For internal use only -- washes laundry, takes out trash, other # crap. task :house do # ... end # # I prefer this comment style. # task :style do # ... end #### output of rake --tasks: rake complex_task # This comment describes a non-toplevel-task. rake house # crap. Fortunately my own commenting style avoids this problem. Others will likely encounter some annoyance (small or possibly great). One could make the comment-grabber smarter, but the question is: How should a programmer document a top-level task? There is already an API method for doing so: desc. The new comment-to-desc feature does not solve an actual problem or deficiency. There could hundreds of these new magic-comment 'desc's cropping up, making the --tasks output useless. Even one newly-public comment could be an issue (think of a programmer making a veiled complaint about a co-worker). A programmer may have good reason to use '#' instead of 'desc'. Why should a new version of Rake suddenly dismiss that reason? Surely there is someone out there who wrote (0...1000).each do |i| # blah blah ... task "blah#{i}" do # ... end end #### rake --tasks output: rake blah0 # blah blah ... rake blah1 # blah blah ... rake blah10 # blah blah ... rake blah100 # blah blah ... rake blah101 # blah blah ... rake blah102 # blah blah ... rake blah103 # blah blah ... rake blah104 # blah blah ... rake blah105 # blah blah ... rake blah106 # blah blah ... rake blah107 # blah blah ... rake blah108 # blah blah ... rake blah109 # blah blah ... rake blah11 # blah blah ... rake blah110 # blah blah ... rake blah111 # blah blah ... rake blah112 # blah blah ... ... In exchange for annoying that programmer, what do we get in return? Usually compatibility is purposefully broken in order to fix a flaw. What is the flaw in 'desc'? Why is '#' better than 'desc'? The worst-case scenario is an auto-generated web page of the --tasks output. With the new Rake, a password in the comments gets exposed. Previously '#' meant internal documentation for a non-top-level task. Now it means public documentation for a top-level task, an effective alias of 'desc'. For internal docs, leave a space between the comment and the task definition. That is natural for me, but requiring all programmers to do that in all Rakefiles seems rather unnatural. From jim.weirich at gmail.com Mon Feb 28 06:34:02 2011 From: jim.weirich at gmail.com (Jim Weirich) Date: Mon, 28 Feb 2011 06:34:02 -0500 Subject: [Rake-devel] About that new magic comment ... In-Reply-To: References: Message-ID: <2E3F9726-6920-49B8-A6B5-1A390F9E79B2@gmail.com> On Feb 27, 2011, at 11:10 PM, James M. Lawrence wrote: > #### output of rake --tasks: > > rake complex_task # This comment describes a non-toplevel-task. > rake house # crap. Oops. This was experimental code from Dave Thomas. I thought I backed this out when the response on the mailing list was meh for the feature. Thanks for catching this. -- Jim Weirich From quixoticsycophant at gmail.com Mon Feb 28 07:19:23 2011 From: quixoticsycophant at gmail.com (James M. Lawrence) Date: Mon, 28 Feb 2011 07:19:23 -0500 Subject: [Rake-devel] About that new magic comment ... In-Reply-To: References: Message-ID: On Sun, Feb 27, 2011 at 11:10 PM, James M. Lawrence wrote: > Assume the following tasks were written for Rake 0.8.x. Oh no, I had not been following rake-devel during the summer -- there appears to have been a flamewar about this feature. There's something about the automagical nature of it which offends certain sensibilities, I suppose. Indeed when I re-read my previous email it sounds extremely more ranty than I had expected. Though I think the feature is a strange addition, there's obviously more serious changes in the beta. From quixoticsycophant at gmail.com Mon Feb 28 07:24:49 2011 From: quixoticsycophant at gmail.com (James M. Lawrence) Date: Mon, 28 Feb 2011 07:24:49 -0500 Subject: [Rake-devel] About that new magic comment ... In-Reply-To: <2E3F9726-6920-49B8-A6B5-1A390F9E79B2@gmail.com> References: <2E3F9726-6920-49B8-A6B5-1A390F9E79B2@gmail.com> Message-ID: On Mon, Feb 28, 2011 at 6:34 AM, Jim Weirich wrote: > > On Feb 27, 2011, at 11:10 PM, James M. Lawrence wrote: > >> #### output of rake --tasks: >> >> ?rake complex_task ?# This comment describes a non-toplevel-task. >> ?rake house ? ? ? ? # crap. > > Oops. ?This was experimental code from Dave Thomas. ?I thought I backed this out when the response on the mailing list was meh for the feature. > > Thanks for catching this. OK, I hadn't seen this email when I sent my last email five minutes ago. From jim.weirich at gmail.com Mon Feb 28 07:46:28 2011 From: jim.weirich at gmail.com (Jim Weirich) Date: Mon, 28 Feb 2011 07:46:28 -0500 Subject: [Rake-devel] New Beta Version of Rake Message-ID: A new beta version of Rake is out (0.9.0.beta.1) and is ready for folks to kick the tires. It's been a while since the last release and with Eric's help we've been whipping this into shape. Install with: gem install rake --pre The CHANGES file should have all the details. -- Jim Weirich