From dchelimsky at gmail.com Thu May 1 03:20:46 2008 From: dchelimsky at gmail.com (David Chelimsky) Date: Thu, 1 May 2008 02:20:46 -0500 Subject: [rspec-devel] autorspec? Message-ID: <57c63afe0805010020o81c1be6ka01559edd1ca5f1@mail.gmail.com> Hey all - please take a look at http://rspec.lighthouseapp.com/projects/5645/tickets/394 and comment (in the ticket) if you wish. Cheers, David From win at wincent.com Thu May 1 06:06:01 2008 From: win at wincent.com (Wincent Colaiuta) Date: Thu, 1 May 2008 12:06:01 +0200 Subject: [rspec-devel] Back to one repository? In-Reply-To: References: Message-ID: <5613F6FE-4284-4029-88E4-95462C0F0F7E@wincent.com> Disclaimer: I've submitted a few patches to RSpec but I can't claim to be a heavyweight participant in the development process. So bear in mind that my perspective might not might be as well-informed as that of others, but here are my thoughts anyway. Let's think for a moment about who our target audiences are: 1. Vanilla RSpec users These users want to be able to checkout just the RSpec code, so it makes sense that it live in its own repository. 2. Rails RSpec users These users want to be able to checkout this and the RSpec code, so again it makes sense that it live in its own repository. 3. People hacking on RSpec itself It's for this group that rspec-dev.git exists, and it exists (or _should_ exist) for the sole purpose of providing a convenient way of doing the "meta" tasks involved in RSpec development: ie. testing the three main parts of RSpec, setting up the example Rails app, packaging releases and so forth. If something about rspec-dev.git is starting to feel like a PITA then it's obviously not fulfilling its purpose of "providing a _convenient_ way..." 4. Users of the TextMate bundle Obviously, these are members of groups 1, 2 and 3, and need this to live in a separate repo for installation purposes. As I see it, rspec-dev.git should be almost static: once it's set up right there should be very few commits to it and there should be very little ongoing maintenance work on it. The optimal workflow as I envisage it is the following. - Have the developer clone the three or four repos, all in the same directory; ie. git clone ../path/to/rspec-dev.git git clone ../path/to/rspec.git git clone ../path/to/rspec-rails.git git clone ../path/to/rspec-tmbundle.git This is a once-off set-up and doesn't really justify having a Rake task IMO. The idea of having multiple git repos nested inside a master repo makes me feel decidedly uncomfortable. Submodules is the only "supported" way of doing that, and it was tried and rejected because the submodule system is really designed for a different type of problem than the one RSpec is trying to solve. Nesting repos inside one another sets off alarm bells: if they really are _that_ interdependent then why do we have separate repos in the first place? But we want separate repos for ease of end-user consumption, so doesn't that mean that we haven't really achieved a sufficient degree of independence? You should be able to work in these repositories independently of one another without having to worry about too many meta issues. ie. if you have a bug to solve in "rspec" you should be able to work inside that repository and not have to think about the others. Only at the end of the process do you worry about the "meta" issue of running the granddaddy pre_commit task in rspec-dev. - Running the spec suite You should be able to run the spec suite for each of the repositories independently of the others. ie. you should be able to cd into the rspec clone and do a "rake spec" or "spec spec" (why is it "spec spec/ spec?"). Likewise, you should be able to cd into the rspec-rails clone and do "rake spec". Where should the example Rails app go? Evidently inside rspec-rails, ignored appropriately using .gitignore, and with symlinks to the relevant bits. Putting the rspec-rails repo _inside_ the Rails app just seems wrong. If the symlink thing doesn't work (as David indicates) then it's a bug in Rails, I suspect, and should be fixed, but in the meantime a simple Rake task should suffice to do a temporary copy instead of a symlink. - "Meta" tasks So what's left? The "meta" tasks for stuff you do in rspec-dev, like the pre_commit and such. As I said, once rspec-dev is set up "right" it really shouldn't be a maintenance burden and if it is we've done something wrong. If you keep your repos up-to-date before you start working on an issue then there's less time for merge conflicts to arise. If the independence of the repositories is sufficient then you won't want or need to make changes to multiple repos at once, so you should be able to "git pull" in each and have a basically instant fast-forward merge. If the repositories really are isolated and you structure your commits with adequate separation then you should rarely/never need to do a set of commits that span multiple repositories, and if you do you should be doing them in the right order anyway (ie. while adding a new feature to rspec-rails you expose a latent bug in rspec causing failure in rspec rails? obviously the fix to rspec should be independent and go into rspec beforehand anyway). So what does the workflow look like? - you always work on topic branches - ideally, your topic branches should be confined to _one_ of the repos - we can take advantage of the structure of the repositories to provide some convenience scripts for doing things like updating/ rebasing all the repos at once, but the working patterns should be such that these rebases should be "fast forwards" 90% of the time I don't know if I've explained my thinking very well here, but the basic message I was trying to communicate was that: 1. Having multiple repos is a good thing because it makes consumption easy for end users; and RSpec exists for end users. 2. If having multiple repos starts to feel like hard work then its kind of like code smell; it's "maintenance smell" that indicates that something isn't right, but we should be able to fix it. Cheers, Wincent From zach.dennis at gmail.com Thu May 1 09:38:15 2008 From: zach.dennis at gmail.com (Zach Dennis) Date: Thu, 1 May 2008 09:38:15 -0400 Subject: [rspec-devel] Back to one repository? In-Reply-To: <5613F6FE-4284-4029-88E4-95462C0F0F7E@wincent.com> References: <5613F6FE-4284-4029-88E4-95462C0F0F7E@wincent.com> Message-ID: <85d99afe0805010638q4b7d931cq9a8344778115192c@mail.gmail.com> On Thu, May 1, 2008 at 6:06 AM, Wincent Colaiuta wrote: > Disclaimer: I've submitted a few patches to RSpec but I can't claim to be > a heavyweight participant in the development process. So bear in mind that > my perspective might not might be as well-informed as that of others, but > here are my thoughts anyway. > > Let's think for a moment about who our target audiences are: > > 1. Vanilla RSpec users > > These users want to be able to checkout just the RSpec code, so it makes > sense that it live in its own repository. > > 2. Rails RSpec users > > These users want to be able to checkout this and the RSpec code, so again > it makes sense that it live in its own repository. > > 3. People hacking on RSpec itself > > It's for this group that rspec-dev.git exists, and it exists (or _should_ > exist) for the sole purpose of providing a convenient way of doing the > "meta" tasks involved in RSpec development: ie. testing the three main parts > of RSpec, setting up the example Rails app, packaging releases and so forth. > If something about rspec-dev.git is starting to feel like a PITA then it's > obviously not fulfilling its purpose of "providing a _convenient_ way..." > > 4. Users of the TextMate bundle > > Obviously, these are members of groups 1, 2 and 3, and need this to live > in a separate repo for installation purposes. > > As I see it, rspec-dev.git should be almost static: once it's set up right > there should be very few commits to it and there should be very little > ongoing maintenance work on it. > > The optimal workflow as I envisage it is the following. > > - Have the developer clone the three or four repos, all in the same > directory; ie. > > git clone ../path/to/rspec-dev.git > git clone ../path/to/rspec.git > git clone ../path/to/rspec-rails.git > git clone ../path/to/rspec-tmbundle.git > > This is a once-off set-up and doesn't really justify having a Rake task > IMO. > +1 to this. > > The idea of having multiple git repos nested inside a master repo makes me > feel decidedly uncomfortable. Submodules is the only "supported" way of > doing that, and it was tried and rejected because the submodule system is > really designed for a different type of problem than the one RSpec is trying > to solve. Nesting repos inside one another sets off alarm bells: if they > really are _that_ interdependent then why do we have separate repos in the > first place? But we want separate repos for ease of end-user consumption, so > doesn't that mean that we haven't really achieved a sufficient degree of > independence? > > You should be able to work in these repositories independently of one > another without having to worry about too many meta issues. ie. if you have > a bug to solve in "rspec" you should be able to work inside that repository > and not have to think about the others. Only at the end of the process do > you worry about the "meta" issue of running the granddaddy pre_commit task > in rspec-dev. > > - Running the spec suite > > You should be able to run the spec suite for each of the repositories > independently of the others. ie. you should be able to cd into the rspec > clone and do a "rake spec" or "spec spec" (why is it "spec spec/spec?"). > > Likewise, you should be able to cd into the rspec-rails clone and do "rake > spec". Where should the example Rails app go? Evidently inside rspec-rails, > ignored appropriately using .gitignore, and with symlinks to the relevant > bits. Putting the rspec-rails repo _inside_ the Rails app just seems wrong. > If the symlink thing doesn't work (as David indicates) then it's a bug in > Rails, I suspect, and should be fixed, but in the meantime a simple Rake > task should suffice to do a temporary copy instead of a symlink. Micah Alles from Atomic Object wrote a tool called foundry last year (although I see on rubyforge it never released any files), but I have a copy of it from him that I've been using personally for plugin testing. It allows you to test plugins against any version of Rails. I wonder if this would work well for rspec-rails. It basically works by creating a cache of Rails versions and a Rails application for each version. You can go into the directory of the plugin in question and run "foundry test" or "foundry test 2.0.2" or "foundry test edge" (you get the idea) and it will copy that plugin into the rails application for each version it is going to test it against. I've recently modified my foundry to support a .foundry file which gives you before/after commands so you can copy over required application files. For example I have spec/rails_root/ which has some app/controllers in order to test a Selenium plugin and I have a before command which tells it do copy over those files into the example rails application app/controllers/* directory. It also is told how-to start selenium before the tests run and stop it after its done. The advantage of this is that you get to stop worrying about carrying around a full fledge Rails application inside your rspec-rails repository, but it's still super easy to test against Rails (all versions or just specific ones). I don't know everything required for rspec-rails to be tested, but it seems like this may be a viable approach. WDYT? -- Zach Dennis http://www.continuousthinking.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From dchelimsky at gmail.com Thu May 1 09:50:37 2008 From: dchelimsky at gmail.com (David Chelimsky) Date: Thu, 1 May 2008 08:50:37 -0500 Subject: [rspec-devel] Back to one repository? In-Reply-To: <5613F6FE-4284-4029-88E4-95462C0F0F7E@wincent.com> References: <5613F6FE-4284-4029-88E4-95462C0F0F7E@wincent.com> Message-ID: <255C76DD-35EF-49CB-8B34-33F1873F8D6F@gmail.com> Wincent - thank you for taking the time to share your thoughts so thoroughly. Comments in-line. On May 1, 2008, at 5:06 AM, Wincent Colaiuta wrote: > Disclaimer: I've submitted a few patches to RSpec but I can't claim > to be a heavyweight participant in the development process. So bear > in mind that my perspective might not might be as well-informed as > that of others, but here are my thoughts anyway. > > Let's think for a moment about who our target audiences are: > > 1. Vanilla RSpec users > > These users want to be able to checkout just the RSpec code, so it > makes sense that it live in its own repository. > > 2. Rails RSpec users > > These users want to be able to checkout this and the RSpec code, so > again it makes sense that it live in its own repository. > > 3. People hacking on RSpec itself > > It's for this group that rspec-dev.git exists, and it exists (or > _should_ exist) for the sole purpose of providing a convenient way > of doing the "meta" tasks involved in RSpec development: ie. testing > the three main parts of RSpec, setting up the example Rails app, > packaging releases and so forth. If something about rspec-dev.git is > starting to feel like a PITA then it's obviously not fulfilling its > purpose of "providing a _convenient_ way..." > > 4. Users of the TextMate bundle > > Obviously, these are members of groups 1, 2 and 3, and need this to > live in a separate repo for installation purposes. > > As I see it, rspec-dev.git should be almost static: once it's set up > right there should be very few commits to it and there should be > very little ongoing maintenance work on it. > > The optimal workflow as I envisage it is the following. > > - Have the developer clone the three or four repos, all in the same > directory; ie. > > git clone ../path/to/rspec-dev.git > git clone ../path/to/rspec.git > git clone ../path/to/rspec-rails.git > git clone ../path/to/rspec-tmbundle.git > > This is a once-off set-up and doesn't really justify having a Rake > task IMO. > > The idea of having multiple git repos nested inside a master repo > makes me feel decidedly uncomfortable. Submodules is the only > "supported" way of doing that, and it was tried and rejected because > the submodule system is really designed for a different type of > problem than the one RSpec is trying to solve. Nesting repos inside > one another sets off alarm bells: if they really are _that_ > interdependent then why do we have separate repos in the first > place? But we want separate repos for ease of end-user consumption, > so doesn't that mean that we haven't really achieved a sufficient > degree of independence? This is more or less how we had it set up in svn. One repo, yes, but rspec and rspec_on_rails up at the root. The workflow problem with this setup is that you have to have the rspec and (now) rspec-rails directories in example_rails_app/vendor/plugins in order to run the specs for rspec-rails. The way we were doing that before was to actually copy them down in the pre_commit task - a workflow nightmare. We can't just symlink them for two reasons - developers using windows AND for some reason unbeknownst to me, rails won't see the generators in rspec-rails if rspec-rails is symlinked from vendor/plugins. Crazy! If someone out there can solve that problem it would be a great help. > You should be able to work in these repositories independently of > one another without having to worry about too many meta issues. ie. > if you have a bug to solve in "rspec" you should be able to work > inside that repository and not have to think about the others. Only > at the end of the process do you worry about the "meta" issue of > running the granddaddy pre_commit task in rspec-dev. This is actually the case for the rspec repo. > - Running the spec suite > > You should be able to run the spec suite for each of the > repositories independently of the others. ie. you should be able to > cd into the rspec clone and do a "rake spec" or "spec spec" (why is > it "spec spec/spec?"). You can run "rake spec" or "bin/spec spec" - the reason for spec/spec (which is not necessary to include on the command line when running the specs) is to keep it parallel with the lib directory. We have spec/ spec/matchers, for example, which has specs for lib/spec/matchers. > Likewise, you should be able to cd into the rspec-rails clone and do > "rake spec". Where should the example Rails app go? Evidently inside > rspec-rails, ignored appropriately using .gitignore, and with > symlinks to the relevant bits. Putting the rspec-rails repo _inside_ > the Rails app just seems wrong. If the symlink thing doesn't work > (as David indicates) then it's a bug in Rails, I suspect, and should > be fixed, but in the meantime a simple Rake task should suffice to > do a temporary copy instead of a symlink. That's an interesting idea that I'm open to exploring. > - "Meta" tasks > > So what's left? The "meta" tasks for stuff you do in rspec-dev, like > the pre_commit and such. As I said, once rspec-dev is set up "right" > it really shouldn't be a maintenance burden and if it is we've done > something wrong. > > If you keep your repos up-to-date before you start working on an > issue then there's less time for merge conflicts to arise. If the > independence of the repositories is sufficient then you won't want > or need to make changes to multiple repos at once, so you should be > able to "git pull" in each and have a basically instant fast-forward > merge. If the repositories really are isolated and you structure > your commits with adequate separation then you should rarely/never > need to do a set of commits that span multiple repositories, and if > you do you should be doing them in the right order anyway (ie. while > adding a new feature to rspec-rails you expose a latent bug in rspec > causing failure in rspec rails? obviously the fix to rspec should be > independent and go into rspec beforehand anyway). One thing to keep in mind here is that rspec-rails is very closely bound to rspec. I think rspec has improved in terms of logical extension points, but if we really want to decouple rspec-rails from rspec's internals, we're going to have to first make a concerted effort to define and commit to a formalized extension API and use that API in rspec-rails. Until that is fully thought out and enacted, rspec- rails will continue to depend on internals of rspec and will need to move with every turn rspec takes. > So what does the workflow look like? > > - you always work on topic branches > > - ideally, your topic branches should be confined to _one_ of the > repos > > - we can take advantage of the structure of the repositories to > provide some convenience scripts for doing things like updating/ > rebasing all the repos at once, but the working patterns should be > such that these rebases should be "fast forwards" 90% of the time > > I don't know if I've explained my thinking very well here, but the > basic message I was trying to communicate was that: > > 1. Having multiple repos is a good thing because it makes > consumption easy for end users; and RSpec exists for end users. > > 2. If having multiple repos starts to feel like hard work then its > kind of like code smell; it's "maintenance smell" that indicates > that something isn't right, but we should be able to fix it. I agree with almost all of this in principle. I think, however, that the current burden is not that much to bear and we have over 200 open tickets in lighthouse. Admittedly, a lower barrier to entry for developers might encourage more people to be taking on those tickets, but I rarely see people in the community submitting patches to solve existing tickets - they usually contribute patches to solve their own tickets. We should keep this on the radar, and I welcome thoughts on how to best approach it. Cheers, David > Cheers, > Wincent From dchelimsky at gmail.com Thu May 1 09:56:07 2008 From: dchelimsky at gmail.com (David Chelimsky) Date: Thu, 1 May 2008 08:56:07 -0500 Subject: [rspec-devel] Back to one repository? In-Reply-To: <85d99afe0805010638q4b7d931cq9a8344778115192c@mail.gmail.com> References: <5613F6FE-4284-4029-88E4-95462C0F0F7E@wincent.com> <85d99afe0805010638q4b7d931cq9a8344778115192c@mail.gmail.com> Message-ID: <28BFCE52-1AA2-4471-BB8F-90FA2EC8F850@gmail.com> On May 1, 2008, at 8:38 AM, Zach Dennis wrote: > On Thu, May 1, 2008 at 6:06 AM, Wincent Colaiuta > wrote: > Disclaimer: I've submitted a few patches to RSpec but I can't claim > to be a heavyweight participant in the development process. So bear > in mind that my perspective might not might be as well-informed as > that of others, but here are my thoughts anyway. > > Let's think for a moment about who our target audiences are: > > 1. Vanilla RSpec users > > These users want to be able to checkout just the RSpec code, so it > makes sense that it live in its own repository. > > 2. Rails RSpec users > > These users want to be able to checkout this and the RSpec code, so > again it makes sense that it live in its own repository. > > 3. People hacking on RSpec itself > > It's for this group that rspec-dev.git exists, and it exists (or > _should_ exist) for the sole purpose of providing a convenient way > of doing the "meta" tasks involved in RSpec development: ie. testing > the three main parts of RSpec, setting up the example Rails app, > packaging releases and so forth. If something about rspec-dev.git is > starting to feel like a PITA then it's obviously not fulfilling its > purpose of "providing a _convenient_ way..." > > 4. Users of the TextMate bundle > > Obviously, these are members of groups 1, 2 and 3, and need this to > live in a separate repo for installation purposes. > > As I see it, rspec-dev.git should be almost static: once it's set up > right there should be very few commits to it and there should be > very little ongoing maintenance work on it. > > The optimal workflow as I envisage it is the following. > > - Have the developer clone the three or four repos, all in the same > directory; ie. > > git clone ../path/to/rspec-dev.git > git clone ../path/to/rspec.git > git clone ../path/to/rspec-rails.git > git clone ../path/to/rspec-tmbundle.git > > This is a once-off set-up and doesn't really justify having a Rake > task IMO. > > +1 to this. > > > > The idea of having multiple git repos nested inside a master repo > makes me feel decidedly uncomfortable. Submodules is the only > "supported" way of doing that, and it was tried and rejected because > the submodule system is really designed for a different type of > problem than the one RSpec is trying to solve. Nesting repos inside > one another sets off alarm bells: if they really are _that_ > interdependent then why do we have separate repos in the first > place? But we want separate repos for ease of end-user consumption, > so doesn't that mean that we haven't really achieved a sufficient > degree of independence? > > You should be able to work in these repositories independently of > one another without having to worry about too many meta issues. ie. > if you have a bug to solve in "rspec" you should be able to work > inside that repository and not have to think about the others. Only > at the end of the process do you worry about the "meta" issue of > running the granddaddy pre_commit task in rspec-dev. > > - Running the spec suite > > You should be able to run the spec suite for each of the > repositories independently of the others. ie. you should be able to > cd into the rspec clone and do a "rake spec" or "spec spec" (why is > it "spec spec/spec?"). > > Likewise, you should be able to cd into the rspec-rails clone and do > "rake spec". Where should the example Rails app go? Evidently inside > rspec-rails, ignored appropriately using .gitignore, and with > symlinks to the relevant bits. Putting the rspec-rails repo _inside_ > the Rails app just seems wrong. If the symlink thing doesn't work > (as David indicates) then it's a bug in Rails, I suspect, and should > be fixed, but in the meantime a simple Rake task should suffice to > do a temporary copy instead of a symlink. > > Micah Alles from Atomic Object wrote a tool called foundry last year > (although I see on rubyforge it never released any files), but I > have a copy of it from him that I've been using personally for > plugin testing. It allows you to test plugins against any version of > Rails. I wonder if this would work well for rspec-rails. It > basically works by creating a cache of Rails versions and a Rails > application for each version. A separate app for each version? > You can go into the directory of the plugin in question and run > "foundry test" or "foundry test 2.0.2" or "foundry test edge" (you > get the idea) and it will copy that plugin into the rails > application for each version it is going to test it against. > > I've recently modified my foundry to support a .foundry file which > gives you before/after commands so you can copy over required > application files. For example I have spec/rails_root/ which has > some app/controllers in order to test a Selenium plugin and I have a > before command which tells it do copy over those files into the > example rails application app/controllers/* directory. It also is > told how-to start selenium before the tests run and stop it after > its done. > > The advantage of this is that you get to stop worrying about > carrying around a full fledge Rails application inside your rspec- > rails repository, but it's still super easy to test against Rails > (all versions or just specific ones). > > I don't know everything required for rspec-rails to be tested, but > it seems like this may be a viable approach. WDYT? We currently have specs split between the example rails app and the rspec-rails/spec directories. That creates an unfortunate coupling to the example rails app to achieve the level of coverage we have. Some history - it started off that ALL of the specs were in the example rails app and none were in the rspec-rails directory. So we're part way where we want to be. I think we'd need to solve that problem before we could do something like this. But I'm open to it. Cheers, David -------------- next part -------------- An HTML attachment was scrubbed... URL: From undees at gmail.com Thu May 1 11:19:04 2008 From: undees at gmail.com (Ian Dees) Date: Thu, 1 May 2008 08:19:04 -0700 Subject: [rspec-devel] Back to one repository? Message-ID: Hi, all. Quoth David: > We also need to consider the Ruby developer who doesn't use rails. We'd be forcing that user to clone a bunch of stuff they don't need. I'm not sure how important an issue that is when weighed against everything else, but it is certainly a consideration. I can at least offer one data point on this note. Most of my RSpec work is non-Rails, and I don't mind having the Rails stuff in there. The amount of extra disk space and clone time it adds doesn't even show up on the radar. If a new layout required me to drill down into example_rails_app to get at the code, that wouldn't be the end of the world, especially if we had a symlink at the top level or an explanation in the README. The extra conceptual effort is about the same as running rake git:update. --Ian From tastapod at gmail.com Fri May 2 16:00:25 2008 From: tastapod at gmail.com (Dan North) Date: Fri, 2 May 2008 21:00:25 +0100 Subject: [rspec-devel] Back to one repository? In-Reply-To: References: Message-ID: Hi folks. Are we trying to solve the wrong problem? Type 1: vanilla rspec user - gem install rspec --source http://rspec.info/rspec-edge.gem Type 2: rails rspec user - gem install rspec --source http://rspec.info/rspec-edge.gem Type 3: rspec hacker - git clone Type 4: textmate bundle user - however textmate bundles are usually packaged up, as a wget I'm coming from the java world where I guess I use around a dozen open source libraries on a regular basis. I almost never check out the sources from scm - I just download the jars (occasionally with source zips). For bleeding-edge versions of java projects they often provide nightly builds. The java world is just catching up with gem-style dependency management, but even without that it's easy to keep up with gem install takes a source url, so providing edge gems should be as easy as having an automated build on every commit that builds and publishes the gems. We can also bundle the examples, docs & internal specs with the gem for reference and inspiration. (The ramaze gem is a really nice example of this.) The use cases should determine the end artifacts of a build process, rather than the way we should be structuring the source repo. The source repo should be structured to make it easiest to navigate and find code. I'd love to be able to step up and offer to put a CI build in place, but I don't have the bandwidth at the moment. I'm happy to work with anyone who wants to take it up though. Cheers, Dan 2008/5/1 Ian Dees : > Hi, all. > > Quoth David: > > > We also need to consider the Ruby developer who doesn't use rails. We'd > be forcing that user to clone a bunch of stuff they don't need. I'm not sure > how important an issue that is when weighed against everything else, but it > is certainly a consideration. > > I can at least offer one data point on this note. Most of my RSpec > work is non-Rails, and I don't mind having the Rails stuff in there. > The amount of extra disk space and clone time it adds doesn't even > show up on the radar. > > If a new layout required me to drill down into example_rails_app to > get at the code, that wouldn't be the end of the world, especially if > we had a symlink at the top level or an explanation in the README. > The extra conceptual effort is about the same as running rake > git:update. > > --Ian > _______________________________________________ > rspec-devel mailing list > rspec-devel at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-devel > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mlangenberg at gmail.com Fri May 2 16:27:06 2008 From: mlangenberg at gmail.com (Matthijs Langenberg) Date: Fri, 2 May 2008 22:27:06 +0200 Subject: [rspec-devel] Back to one repository? In-Reply-To: References: Message-ID: <27c0ac6d0805021327i1fa113bch81a8b7c612b3d5fa@mail.gmail.com> +1 Dan, a CI with nightly gem builds would be great. Still, what to do with 'Type 3: rspec hacker'? How should that repository look? - Matt On Fri, May 2, 2008 at 10:00 PM, Dan North wrote: > Hi folks. Are we trying to solve the wrong problem? > > Type 1: vanilla rspec user > > - gem install rspec --source http://rspec.info/rspec-edge.gem > > Type 2: rails rspec user > > - gem install rspec --source http://rspec.info/rspec-edge.gem > > Type 3: rspec hacker > > - git clone > > Type 4: textmate bundle user > > - however textmate bundles are usually packaged up, as a wget > > > I'm coming from the java world where I guess I use around a dozen open > source libraries on a regular basis. I almost never check out the sources > from scm - I just download the jars (occasionally with source zips). For > bleeding-edge versions of java projects they often provide nightly builds. > The java world is just catching up with gem-style dependency management, but > even without that it's easy to keep up with > > gem install takes a source url, so providing edge gems should be as easy > as having an automated build on every commit that builds and publishes the > gems. We can also bundle the examples, docs & internal specs with the gem > for reference and inspiration. (The ramaze gem is a really nice example of > this.) > > The use cases should determine the end artifacts of a build process, > rather than the way we should be structuring the source repo. The source > repo should be structured to make it easiest to navigate and find code. > > I'd love to be able to step up and offer to put a CI build in place, but I > don't have the bandwidth at the moment. I'm happy to work with anyone who > wants to take it up though. > > Cheers, > Dan > > > 2008/5/1 Ian Dees : > > Hi, all. > > > > Quoth David: > > > > > We also need to consider the Ruby developer who doesn't use rails. > > We'd be forcing that user to clone a bunch of stuff they don't need. I'm not > > sure how important an issue that is when weighed against everything else, > > but it is certainly a consideration. > > > > I can at least offer one data point on this note. Most of my RSpec > > work is non-Rails, and I don't mind having the Rails stuff in there. > > The amount of extra disk space and clone time it adds doesn't even > > show up on the radar. > > > > If a new layout required me to drill down into example_rails_app to > > get at the code, that wouldn't be the end of the world, especially if > > we had a symlink at the top level or an explanation in the README. > > The extra conceptual effort is about the same as running rake > > git:update. > > > > --Ian > > _______________________________________________ > > rspec-devel mailing list > > rspec-devel at rubyforge.org > > http://rubyforge.org/mailman/listinfo/rspec-devel > > > > > _______________________________________________ > rspec-devel mailing list > rspec-devel at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-devel > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mailing_lists at railsnewbie.com Tue May 13 03:25:54 2008 From: mailing_lists at railsnewbie.com (Scott Taylor) Date: Tue, 13 May 2008 03:25:54 -0400 Subject: [rspec-devel] Stubbing all instances Message-ID: I just submitted a patch for stub_all_instances to the lighthouse tracker. I know that there are a ton of patches open, but I think this is a feature request which has been open for a while and would bring rspec's mock library up to speed with Mocha. My last patch got lost among the shuffle in the tracker, so I'm wondering if one of the project admins could take a look at it and give me some feedback sooner rather than later, as time permits. Best, Scott From dchelimsky at gmail.com Tue May 13 07:48:15 2008 From: dchelimsky at gmail.com (David Chelimsky) Date: Tue, 13 May 2008 06:48:15 -0500 Subject: [rspec-devel] rspec/autotest conflict w/ other spec libraries Message-ID: <5510DFA7-AE3E-413F-AC8D-A3EDFF47D58D@gmail.com> Hi all, Anybody care to comment on http://rspec.lighthouseapp.com/projects/5645/tickets/394? Thanks, David From chris at edendevelopment.co.uk Thu May 15 05:58:47 2008 From: chris at edendevelopment.co.uk (Chris Parsons) Date: Thu, 15 May 2008 10:58:47 +0100 Subject: [rspec-devel] What should I work on? Message-ID: <4A381FA9-DAB1-4750-8FD2-8C0AF80AE702@edendevelopment.co.uk> Hi guys, I'd love to dig in and help with rspec development. Is there any particular lighthouse tasks that need picking up, or should I just dive in and attempt to repro/fix unassigned bugs? Thanks Chris From dchelimsky at gmail.com Thu May 15 07:11:16 2008 From: dchelimsky at gmail.com (David Chelimsky) Date: Thu, 15 May 2008 06:11:16 -0500 Subject: [rspec-devel] What should I work on? In-Reply-To: <4A381FA9-DAB1-4750-8FD2-8C0AF80AE702@edendevelopment.co.uk> References: <4A381FA9-DAB1-4750-8FD2-8C0AF80AE702@edendevelopment.co.uk> Message-ID: <4ADC2ABF-185F-47E0-A899-9272B101924C@gmail.com> On May 15, 2008, at 4:58 AM, Chris Parsons wrote: > Hi guys, > > I'd love to dig in and help with rspec development. Is there any > particular lighthouse tasks that need picking up, or should I just > dive in and attempt to repro/fix unassigned bugs? You can even work on assigned bugs as long as you coordinate w/ the person to whom they are assigned to avoid double work. What I'd recommend is that you start by finding tickets that you're interested in. If you want to play it safe, check with us before you spend a bunch of time on a ticket to make sure that it's something that we feel is aligned with rspec's goals and has at least some sense of priority. Thanks a lot for offering to help out! Cheers, David > Thanks > Chris > > _______________________________________________ > rspec-devel mailing list > rspec-devel at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-devel From joshknowles at gmail.com Mon May 19 16:58:29 2008 From: joshknowles at gmail.com (Josh Knowles) Date: Mon, 19 May 2008 16:58:29 -0400 Subject: [rspec-devel] links to github on rspec.info Message-ID: So unless I'm missing something I don't see any reference to how to contribute using Git/GitHub on rspec.info. Has anyone started this already? If not is a patch for this of interest to the team? -- Josh Knowles phone: 509-979-1593 email: joshknowles at gmail.com web: http://joshknowles.com From dchelimsky at gmail.com Mon May 19 17:03:28 2008 From: dchelimsky at gmail.com (David Chelimsky) Date: Mon, 19 May 2008 16:03:28 -0500 Subject: [rspec-devel] links to github on rspec.info In-Reply-To: References: Message-ID: <22075CEE-8B18-4FE9-BD0A-140BAF4476F0@gmail.com> As of now the rspec.info site is maintained with releases. That info when be updated with the 1.4 release. It's probably not yet, so feel free to submit a patch, but you'll have to patch the source at github - catch 22! On May 19, 2008, at 3:58 PM, Josh Knowles wrote: > So unless I'm missing something I don't see any reference to how to > contribute using Git/GitHub on rspec.info. Has anyone started this > already? If not is a patch for this of interest to the team? > > -- > Josh Knowles > phone: 509-979-1593 > email: joshknowles at gmail.com > web: http://joshknowles.com > _______________________________________________ > rspec-devel mailing list > rspec-devel at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-devel From brian.takita at gmail.com Thu May 22 02:31:17 2008 From: brian.takita at gmail.com (Brian Takita) Date: Wed, 21 May 2008 23:31:17 -0700 Subject: [rspec-devel] Issues running example rails app specs Message-ID: <1d7ddd110805212331q7c221604t84776dd9194190e2@mail.gmail.com> Hey, I was wondering if anybody else is having issues with the example rails app specs. When I'm using sqlite, I have issues with the whole schema_migrations table in Rails >= 2.0.1 and schema_info in Rails <= 2.0.0. When I'm using mysql, I have issues with stubbed_model_spec.rb 1) 'stub_model should raise when hitting the db' FAILED expected Spec::Rails::IllegalDataAccessException with message matching /stubbed models are not allowed to access the database/ but nothing was raised ./vendor/plugins/rspec-rails/spec/rails/mocks/stub_model_spec.rb:42: Thanks, Brian From pergesu at gmail.com Thu May 22 02:49:21 2008 From: pergesu at gmail.com (Pat Maddox) Date: Wed, 21 May 2008 23:49:21 -0700 Subject: [rspec-devel] Issues running example rails app specs In-Reply-To: <1d7ddd110805212331q7c221604t84776dd9194190e2@mail.gmail.com> References: <1d7ddd110805212331q7c221604t84776dd9194190e2@mail.gmail.com> Message-ID: <810a540e0805212349o58890ed2q6cdc4d36655709dd@mail.gmail.com> > When I'm using sqlite, I have issues with the whole schema_migrations > table in Rails >= 2.0.1 and schema_info in Rails <= 2.0.0. I've run into this as well. I've got a couple ideas on how to handle this. The first is to use db:drop and db:create instead of migrating down, for Rails versions that support those tasks. My other idea is to have a db/migrations/templates directory with the content of the migrations, and then for each one run "script/generate migration the_migration_name," then dump the content into the newly created migration file. This has the advantage of using Rails' migration generation so we don't have a migration number mismatch. The main disadvantage I see is that it'd require an extra step to generate the migrations before we can run individual specs. Pat From dchelimsky at gmail.com Thu May 22 08:29:24 2008 From: dchelimsky at gmail.com (David Chelimsky) Date: Thu, 22 May 2008 07:29:24 -0500 Subject: [rspec-devel] Issues running example rails app specs In-Reply-To: <810a540e0805212349o58890ed2q6cdc4d36655709dd@mail.gmail.com> References: <1d7ddd110805212331q7c221604t84776dd9194190e2@mail.gmail.com> <810a540e0805212349o58890ed2q6cdc4d36655709dd@mail.gmail.com> Message-ID: <47A117FC-9790-4BEC-BBF0-189C51736974@gmail.com> On May 22, 2008, at 1:49 AM, Pat Maddox wrote: >> When I'm using sqlite, I have issues with the whole schema_migrations >> table in Rails >= 2.0.1 and schema_info in Rails <= 2.0.0. > > I've run into this as well. > > I've got a couple ideas on how to handle this. The first is to use > db:drop and db:create instead of migrating down, for Rails versions > that support those tasks. +1 > My other idea is to have a > db/migrations/templates directory with the content of the migrations, > and then for each one run "script/generate migration > the_migration_name," then dump the content into the newly created > migration file. This has the advantage of using Rails' migration > generation so we don't have a migration number mismatch. The main > disadvantage I see is that it'd require an extra step to generate the > migrations before we can run individual specs. +- 1 :) David > > > Pat > _______________________________________________ > rspec-devel mailing list > rspec-devel at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-devel From dchelimsky at gmail.com Thu May 22 10:07:15 2008 From: dchelimsky at gmail.com (David Chelimsky) Date: Thu, 22 May 2008 09:07:15 -0500 Subject: [rspec-devel] Issues running example rails app specs In-Reply-To: <1d7ddd110805212331q7c221604t84776dd9194190e2@mail.gmail.com> References: <1d7ddd110805212331q7c221604t84776dd9194190e2@mail.gmail.com> Message-ID: <8B6817DB-4B20-4952-A48F-17D99FCA77AF@gmail.com> On May 22, 2008, at 1:31 AM, Brian Takita wrote: > When I'm using mysql, I have issues with stubbed_model_spec.rb > > 1) > 'stub_model should raise when hitting the db' FAILED > expected Spec::Rails::IllegalDataAccessException with message matching > /stubbed models are not allowed to access the database/ but nothing > was raised > ./vendor/plugins/rspec-rails/spec/rails/mocks/stub_model_spec.rb:42: I haven't run against mysql in a while so hadn't seen this. I see you made some commits yesterday - any chance you already fixed this problem? From pergesu at gmail.com Thu May 22 10:09:43 2008 From: pergesu at gmail.com (Pat Maddox) Date: Thu, 22 May 2008 07:09:43 -0700 Subject: [rspec-devel] Issues running example rails app specs In-Reply-To: <47A117FC-9790-4BEC-BBF0-189C51736974@gmail.com> References: <1d7ddd110805212331q7c221604t84776dd9194190e2@mail.gmail.com> <810a540e0805212349o58890ed2q6cdc4d36655709dd@mail.gmail.com> <47A117FC-9790-4BEC-BBF0-189C51736974@gmail.com> Message-ID: <810a540e0805220709o2983ee62t24d48c4d3164f0b@mail.gmail.com> I'm pretty sure this is fixed now. Brian made http://github.com/dchelimsky/rspec-dev/commit/d1782a195aa6040f3ef1c1654117e750bbf7a042 last night, and pre_commit is green for me all the way through. Pat From jim.weirich at gmail.com Thu May 22 23:37:44 2008 From: jim.weirich at gmail.com (Jim Weirich) Date: Thu, 22 May 2008 20:37:44 -0700 Subject: [rspec-devel] RSpec mocks running when Flexmock is configured Message-ID: <890401FC-9662-4595-B121-2EE084571EE6@gmail.com> I've been debugging a problem with mocks in RSpec. I've configured RSpec to use flexmock, but the RSpec mocking framework still adds its should_receive method onto every object in the system, including flexmock objects. These RSpec mocks are never torn down because the teardown mechanism is invoking flexmock's teardown. Here's an example of the problem: -----><--snip--><------------------- require File.expand_path(File.dirname(__FILE__) + "/../../config/ environment") require 'spec' require 'spec/rails' Spec::Runner.configure do |config| config.mock_with :flexmock end describe "Mock Bug" do it "should create flexmock expectation" do expectation = flexmock(Object).should_receive(:xyzzy) expectation.class.should == FlexMock::CompositeExpectation end end -----><--snip--><------------------- And here is the output of the run: -----><--snip--><------------------- 1) 'Mock Bug should create flexmock expectation' FAILED expected: FlexMock::CompositeExpectation, got: Spec::Mocks::MessageExpectation (using ==) -----><--snip--><------------------- This is in the spec/models directory of a very simple demo Rails application. If I comment out the require on environment and the require on spec/rails, the spec executes as expected (indicating some kind of interaction with Rails is part of the problem). Anybody got any ideas on this one? I could really use some help from someone who understand the RSpec mocking infrastructure better than I do. I'd really like to get flexmock working in this area. More info: Rails 2.0.2, RSpec 1.1.3, FlexMock 0.8.1, all on Mac OS X 10.5.2. Thanks. -- -- Jim Weirich -- jim.weirich at gmail.com From jim.weirich at gmail.com Fri May 23 19:20:32 2008 From: jim.weirich at gmail.com (Jim Weirich) Date: Fri, 23 May 2008 19:20:32 -0400 Subject: [rspec-devel] RSpec mocks running when Flexmock is configured In-Reply-To: <890401FC-9662-4595-B121-2EE084571EE6@gmail.com> References: <890401FC-9662-4595-B121-2EE084571EE6@gmail.com> Message-ID: On May 22, 2008, at 11:37 PM, Jim Weirich wrote: > I've been debugging a problem with mocks in RSpec. I've configured > RSpec to use flexmock, but the RSpec mocking framework still adds > its should_receive method onto every object in the system, including > flexmock objects. These RSpec mocks are never torn down because the > teardown mechanism is invoking flexmock's teardown. Ok, I've investigated the problem further. The issue is caused in spec/rails by the inclusion of the render_observer file. Render_observer unconditionally loads the rspec mocks file without checking for configured mock library. This is problematic in two areas: (1) RSpec mock teardown facility only supports a single mock library (AFAIK, I recall being told this was a design decision). Once a different mock library is configured, RSpec mocks will not be torn down. (2) The RSpec mock library globally installs a should_receive method on every object in the system, interfering with other mock libraries. Solutions I see are: (A) Fix render_observer to work with the configured mock library. (B) Allow RSpec to support multiple simultaneous mocking frameworks. -- -- Jim Weirich -- jim.weirich at gmail.com From dchelimsky at gmail.com Sat May 24 09:15:35 2008 From: dchelimsky at gmail.com (David Chelimsky) Date: Sat, 24 May 2008 08:15:35 -0500 Subject: [rspec-devel] RSpec mocks running when Flexmock is configured In-Reply-To: References: <890401FC-9662-4595-B121-2EE084571EE6@gmail.com> Message-ID: On May 23, 2008, at 6:20 PM, Jim Weirich wrote: > On May 22, 2008, at 11:37 PM, Jim Weirich wrote: > >> I've been debugging a problem with mocks in RSpec. I've configured >> RSpec to use flexmock, but the RSpec mocking framework still adds >> its should_receive method onto every object in the system, >> including flexmock objects. These RSpec mocks are never torn down >> because the teardown mechanism is invoking flexmock's teardown. > > Ok, I've investigated the problem further. The issue is caused in > spec/rails by the inclusion of the render_observer file. > Render_observer unconditionally loads the rspec mocks file without > checking for configured mock library. > > This is problematic in two areas: > > (1) RSpec mock teardown facility only supports a single mock library > (AFAIK, I recall being told this was a design decision). Once a > different mock library is configured, RSpec mocks will not be torn > down. > > (2) The RSpec mock library globally installs a should_receive method > on every object in the system, interfering with other mock libraries. > > Solutions I see are: > > (A) Fix render_observer to work with the configured mock library. > > (B) Allow RSpec to support multiple simultaneous mocking frameworks. Hey Jim - thanks for taking the time to figure this out. I think that changing rspec to support multiple mocking frameworks would require removing the Object-invasion you speak of. If I were starting from scratch, that's definitely the direction I'd want to go. Given that there are a lot of examples in the world that exploit that, it would be counter-productive for us to change that decision at this point. Changing render_observer to support different libraries would require rspec to follow the maintenance of those libraries. That's not really a viable option in my view. We can, however, do a better job of decoupling things. I have some thoughts about that but I have no time right this second so I'll follow up later today. Cheers, David From jim.weirich at gmail.com Sat May 24 11:58:30 2008 From: jim.weirich at gmail.com (Jim Weirich) Date: Sat, 24 May 2008 11:58:30 -0400 Subject: [rspec-devel] RSpec mocks running when Flexmock is configured In-Reply-To: References: <890401FC-9662-4595-B121-2EE084571EE6@gmail.com> Message-ID: <8F2FA9A2-52EA-4FD2-B5F9-0403239067AC@gmail.com> On May 24, 2008, at 9:15 AM, David Chelimsky wrote: > I think that changing rspec to support multiple mocking frameworks > would require removing the Object-invasion you speak of. If I were > starting from scratch, that's definitely the direction I'd want to > go. Given that there are a lot of examples in the world that exploit > that, it would be counter-productive for us to change that decision > at this point. Agreed. I've changed flexmock so that it will override the global "should_receive" with its own definition, but only on objects that are explicitly given to flexmock for mocking. That solves half the problem. The other half of the problem is that RSpec mocks are not torn down once flexmock is configured. Supporting multiple mocking frameworks might be as easy as making sure all mock libraries get properly "hooked" into the teardown process. I see no reason why flexmock couldn't live comfortably with the RSpec mock in that case. -- -- Jim Weirich -- jim.weirich at gmail.com From dchelimsky at gmail.com Sat May 24 12:40:05 2008 From: dchelimsky at gmail.com (David Chelimsky) Date: Sat, 24 May 2008 11:40:05 -0500 Subject: [rspec-devel] RSpec mocks running when Flexmock is configured In-Reply-To: <8F2FA9A2-52EA-4FD2-B5F9-0403239067AC@gmail.com> References: <890401FC-9662-4595-B121-2EE084571EE6@gmail.com> <8F2FA9A2-52EA-4FD2-B5F9-0403239067AC@gmail.com> Message-ID: <61890C86-B56A-4E61-858C-74C4B4131B25@gmail.com> On May 24, 2008, at 10:58 AM, Jim Weirich wrote: > On May 24, 2008, at 9:15 AM, David Chelimsky wrote: > >> I think that changing rspec to support multiple mocking frameworks >> would require removing the Object-invasion you speak of. If I were >> starting from scratch, that's definitely the direction I'd want to >> go. Given that there are a lot of examples in the world that >> exploit that, it would be counter-productive for us to change that >> decision at this point. > > Agreed. I've changed flexmock so that it will override the global > "should_receive" with its own definition, but only on objects that > are explicitly given to flexmock for mocking. That solves half the > problem. The other half of the problem is that RSpec mocks are not > torn down once flexmock is configured. Supporting multiple mocking > frameworks might be as easy as making sure all mock libraries get > properly "hooked" into the teardown process. I see no reason why > flexmock couldn't live comfortably with the RSpec mock in that case. Interesting idea. Any chance we can spend a little while working on this together in Portland? From jim.weirich at gmail.com Sat May 24 15:32:53 2008 From: jim.weirich at gmail.com (Jim Weirich) Date: Sat, 24 May 2008 15:32:53 -0400 Subject: [rspec-devel] RSpec mocks running when Flexmock is configured In-Reply-To: <61890C86-B56A-4E61-858C-74C4B4131B25@gmail.com> References: <890401FC-9662-4595-B121-2EE084571EE6@gmail.com> <8F2FA9A2-52EA-4FD2-B5F9-0403239067AC@gmail.com> <61890C86-B56A-4E61-858C-74C4B4131B25@gmail.com> Message-ID: <1374D929-D2FD-4A3F-9F50-8F179BF6031A@gmail.com> On May 24, 2008, at 12:40 PM, David Chelimsky wrote: > On May 24, 2008, at 10:58 AM, Jim Weirich wrote: > >> On May 24, 2008, at 9:15 AM, David Chelimsky wrote: >> >>> I think that changing rspec to support multiple mocking frameworks >>> would require removing the Object-invasion you speak of. If I were >>> starting from scratch, that's definitely the direction I'd want to >>> go. Given that there are a lot of examples in the world that >>> exploit that, it would be counter-productive for us to change that >>> decision at this point. >> >> Agreed. I've changed flexmock so that it will override the global >> "should_receive" with its own definition, but only on objects that >> are explicitly given to flexmock for mocking. That solves half the >> problem. The other half of the problem is that RSpec mocks are not >> torn down once flexmock is configured. Supporting multiple mocking >> frameworks might be as easy as making sure all mock libraries get >> properly "hooked" into the teardown process. I see no reason why >> flexmock couldn't live comfortably with the RSpec mock in that case. > > Interesting idea. Any chance we can spend a little while working on > this together in Portland? Sounds like a plan! -- -- Jim Weirich -- jim.weirich at gmail.com From dchelimsky at gmail.com Sat May 24 18:59:35 2008 From: dchelimsky at gmail.com (David Chelimsky) Date: Sat, 24 May 2008 17:59:35 -0500 Subject: [rspec-devel] RSpec mocks running when Flexmock is configured In-Reply-To: <61890C86-B56A-4E61-858C-74C4B4131B25@gmail.com> References: <890401FC-9662-4595-B121-2EE084571EE6@gmail.com> <8F2FA9A2-52EA-4FD2-B5F9-0403239067AC@gmail.com> <61890C86-B56A-4E61-858C-74C4B4131B25@gmail.com> Message-ID: On May 24, 2008, at 11:40 AM, David Chelimsky wrote: > On May 24, 2008, at 10:58 AM, Jim Weirich wrote: > >> On May 24, 2008, at 9:15 AM, David Chelimsky wrote: >> >>> I think that changing rspec to support multiple mocking frameworks >>> would require removing the Object-invasion you speak of. If I were >>> starting from scratch, that's definitely the direction I'd want to >>> go. Given that there are a lot of examples in the world that >>> exploit that, it would be counter-productive for us to change that >>> decision at this point. >> >> Agreed. I've changed flexmock so that it will override the global >> "should_receive" with its own definition, but only on objects that >> are explicitly given to flexmock for mocking. That solves half the >> problem. The other half of the problem is that RSpec mocks are not >> torn down once flexmock is configured. Supporting multiple mocking >> frameworks might be as easy as making sure all mock libraries get >> properly "hooked" into the teardown process. I see no reason why >> flexmock couldn't live comfortably with the RSpec mock in that case. > > Interesting idea. Any chance we can spend a little while working on > this together in Portland? I separated the extensions of Object and Class from the rest of the mock framework. render_observer now requires 'spec/mocks/framework' instead of 'spec/mocks' This should solve this problem for you, Jim. Please let me know if it does. You'll need to update both vendor/plugins/rspec and vendor/plugins/ rspec-rails. Cheers, David From dchelimsky at gmail.com Mon May 26 17:52:31 2008 From: dchelimsky at gmail.com (David Chelimsky) Date: Mon, 26 May 2008 16:52:31 -0500 Subject: [rspec-devel] [ANN] RSpec-1.1.4 Message-ID: The RSpec Development Team is happy to announce the release of RSpec-1.1.4. See http://rspec.info/changes.html for details of what changed in this release. For Rails developers: * This release of RSpec supports Rails-2.1.0-RC1, 2.0.2, 1.2.6 More info at http://rspec.info. Cheers, David From aslak.hellesoy at gmail.com Mon May 26 18:29:12 2008 From: aslak.hellesoy at gmail.com (aslak hellesoy) Date: Tue, 27 May 2008 00:29:12 +0200 Subject: [rspec-devel] [rspec-users] [ANN] RSpec-1.1.4 In-Reply-To: References: Message-ID: <8d961d900805261529r5b55cb94pafb14389e482e4d9@mail.gmail.com> On Mon, May 26, 2008 at 11:52 PM, David Chelimsky wrote: > The RSpec Development Team is happy to announce the release of RSpec-1.1.4. > > See http://rspec.info/changes.html for details of what changed in this > release. > Awesome job everybody! Aslak > For Rails developers: > > * This release of RSpec supports Rails-2.1.0-RC1, 2.0.2, 1.2.6 > > More info at http://rspec.info. > > Cheers, > David > _______________________________________________ > rspec-users mailing list > rspec-users at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-users > From tastapod at gmail.com Tue May 27 13:22:27 2008 From: tastapod at gmail.com (Dan North) Date: Tue, 27 May 2008 18:22:27 +0100 Subject: [rspec-devel] [rspec-users] [ANN] RSpec-1.1.4 In-Reply-To: <8d961d900805261529r5b55cb94pafb14389e482e4d9@mail.gmail.com> References: <8d961d900805261529r5b55cb94pafb14389e482e4d9@mail.gmail.com> Message-ID: What Aslak said! 2008/5/26 aslak hellesoy : > On Mon, May 26, 2008 at 11:52 PM, David Chelimsky > wrote: > > The RSpec Development Team is happy to announce the release of > RSpec-1.1.4. > > > > See http://rspec.info/changes.html for details of what changed in this > > release. > > > > Awesome job everybody! > > Aslak > > > For Rails developers: > > > > * This release of RSpec supports Rails-2.1.0-RC1, 2.0.2, 1.2.6 > > > > More info at http://rspec.info. > > > > Cheers, > > David > > _______________________________________________ > > rspec-users mailing list > > rspec-users at rubyforge.org > > http://rubyforge.org/mailman/listinfo/rspec-users > > > _______________________________________________ > rspec-devel mailing list > rspec-devel at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-devel > -------------- next part -------------- An HTML attachment was scrubbed... URL: From antti.tarvainen at iki.fi Wed May 28 03:35:25 2008 From: antti.tarvainen at iki.fi (Antti Tarvainen) Date: Wed, 28 May 2008 10:35:25 +0300 Subject: [rspec-devel] Spec::Rails installation instructions? Message-ID: <5b89e3bd0805280035q71feb8bfi64690e64c92b0a31@mail.gmail.com> Hello. Congratulations on the 1.1.4 release, everyone! I cannot find the Spec::Rails installation instructions at http://rspec.info/documentation/rails/ anymore. Is it just me or are they really missing? Antti T. From dchelimsky at gmail.com Wed May 28 08:23:04 2008 From: dchelimsky at gmail.com (David Chelimsky) Date: Wed, 28 May 2008 07:23:04 -0500 Subject: [rspec-devel] Spec::Rails installation instructions? In-Reply-To: <5b89e3bd0805280035q71feb8bfi64690e64c92b0a31@mail.gmail.com> References: <5b89e3bd0805280035q71feb8bfi64690e64c92b0a31@mail.gmail.com> Message-ID: <568A8747-9995-4E49-802D-655F8EEC1622@gmail.com> On May 28, 2008, at 2:35 AM, Antti Tarvainen wrote: > Hello. > > Congratulations on the 1.1.4 release, everyone! > > I cannot find the Spec::Rails installation instructions at > http://rspec.info/documentation/rails/ anymore. Is it just me or are > they really missing? http://rspec.info/download.html http://github.com/dchelimsky/rspec/wikis/home http://github.com/dchelimsky/rspec-rails/wikis/home Cheers, David From james at imaj.es Thu May 29 15:19:21 2008 From: james at imaj.es (James Cox) Date: Thu, 29 May 2008 20:19:21 +0100 Subject: [rspec-devel] erroneous output when running specs formatted as specdoc.. Message-ID: <14C76B95-1FE3-4F8E-9CF9-9C24319E7FEC@imaj.es> Hey, i see this output: Spec::Rails::Example::ViewExampleGroup Spec::Rails::Example::HelperExampleGroup Spec::Rails::Example::ControllerExampleGroup Spec::Rails::Example::FunctionalExampleGroup Spec::Rails::Example::ModelExampleGroup Spec::Rails::Example::RailsExampleGroup about 2-3 times when running through specs. Looks like someone did some introspection and puts the class they were in... anyone care to shed some other light? :P thanks. james From dchelimsky at gmail.com Thu May 29 17:29:41 2008 From: dchelimsky at gmail.com (David Chelimsky) Date: Thu, 29 May 2008 14:29:41 -0700 Subject: [rspec-devel] erroneous output when running specs formatted as specdoc.. In-Reply-To: <14C76B95-1FE3-4F8E-9CF9-9C24319E7FEC@imaj.es> References: <14C76B95-1FE3-4F8E-9CF9-9C24319E7FEC@imaj.es> Message-ID: <5B839FE2-FB67-4622-BDC5-E1BF6BB6F1A8@gmail.com> On May 29, 2008, at 12:19 PM, James Cox wrote: > Hey, > > i see this output: > > Spec::Rails::Example::ViewExampleGroup > > Spec::Rails::Example::HelperExampleGroup > > Spec::Rails::Example::ControllerExampleGroup > > Spec::Rails::Example::FunctionalExampleGroup > > Spec::Rails::Example::ModelExampleGroup > > Spec::Rails::Example::RailsExampleGroup > > > about 2-3 times when running through specs. Looks like someone did > some introspection and puts the class they were in... It's a bug - already reported: http://rspec.lighthouseapp.com/projects/5645/tickets/412-printout