This should be resolved with http://github.com/technicalpickles/jeweler/commit/4659f338f182fc62ee4f69aabd1e1e823a8de655

Yep, it's as snsnu said.

Ah, ok. My bad, I was on vintrepid's fork which didn't have the changes. Going back to the origin and together all the various commits from the various forks finally got things work correctly. Thanks

Merged... thanks!

... and closed.

Fixed in f50055e

http://twitter.com/defunkt/status/4839646239

argh, so many angels!

I've been thinking about this too, because I'm doing nonprilveged gem installs myself. I'm not sure what the best option is to configure it though.

ENV is probably the simplest. JEWELER_NO_SUDO perhaps?

An environment variable seems to make sense -- but I would make the ENV variable called JEWELER_SUDO. Therefore optional for those not needing sudo. And necessary for those who want to sudo. Make them feel the pain every time they rip wings off angels.

I like the idea of them feeling the pain :)

Agree with the JEWELER_SUDO option :-). I think the community is starting to see the light and switching over to not using sudo to install gems. Jeweler should help encourage that a bit.

Yeah, about inflicting pain... I'm definitely NOT going to do that. I'll have to think about this a little bit.

If anyone were to make patches in a fork in the meantime though...

Agreed. Pain is bad. But a little error message saying "permission denied... please use set JEWELER_SUDO=true, or sudo rake install" wouldn't be too painful.

This is what I'd propose:

• A new env variable that is respected, JEWELER_INSTALL_COMMAND
• This would determine what to call 'install' with
• It will default to sudo gem for now to maintain backwards compatibility
• This will allow for privileged, unprivileged, and jruby installs
• Perhaps warn that the default has been used, and direct to set the environment variable to avoid the warning.

That sounds very reasonable to me!

Partially implemented here, at least the basics of introducing an ENV variable. It'd need some work to be in line with what I proposed.

http://github.com/vintrepid/jeweler/commit/a978642e223ea86ff4fd42f445845ba1dd12ba97

It still seems completely crazy to me to use "sudo gem" by default. sudo is meant to be an override. You can't unoverride it easily (you have to invent a random ENV workaround).

If sudo wasn't the default behavior and I wanted to sudo, i would just run 'sudo rake install'.

Why not get rid of this complexity...?

Well, I'm glad you think my past work is completely crazy, but as is evidence by this ticket, I'm trying to move into the realm of sanity. I hope to see you there soon.

Nah, your past work isn't crazy. It is very helpful. We're all learning as we go (at least I am). I would only classify continuing on with the sudo as default as a wee bit of craziness :-).

So, I reversed my stance a bit. People who need to sudo, will have to run sudo rake install.

Committed at bae6f6c.

love it! less code, and way better. thanks!

Hmm, this is a little interesting.

I'm not sure how I'd reliably guess what 'gem' command to use.

Ah, nevermind. I figured out a way to use RbConfig to figure it out.

FIxed in 873f376.

Merged into master. Sidenote: it's a little easier for me to merge stuff in if they're in feature branches which only include the relevant commits.

Fixed in 1.3.0.

This was fixed in another fork already, just not merged in: http://github.com/sutto/jeweler

Fixed in master.

Fixed in 1.3.0.

The upcoming release handles this. Declaring a RubyforgeTasks or GemcutterTasks adds some extra task dependencies to release, such that they will happen whenever you run rake release.

Fixed in 1.3.0

Can you elaborate on 'git operations immediately fail'?

Try this in the cd block: system 'pwd'

Notice that it is displaying the correct directory at this point. When git is system'd though, it obviously is still in the meta version.

I can't think of any reason why this would happen when jeweler is required and Jeweler::Tasks is instantiated.

I'm pretty sure that this is related to [#37]. There's a patch that works around the problem they were having, but it seems like cd/chdiring into a directory using has some sort of side effect.

I have another workaround in 77d0841.

It's kinda disconcerting though, because I have this suspicion there's a bug lurking in either Dir.chdir, FileUtils.cd, or the git command.

Merged. Thanks for the contribution!

You generally want to wait until the last possible second to bump the version, ie right before the release.

If you bump the version, and at some point generate the gemspec, it will have the new version. If you happen to commit and push this, github will rebuild the gem. Then you decide to release finally. Unfortunately, the gem would have already been built, meaning the tagged release and the gem's source would not be in sync.

This is mainly why it does force a commit.

Could you explain what your work flow generally looks like?

I will try harder to adapt my workflow to jeweler. ;)
I will let you know how it worked! Thanks! :)

Closing for now.

Merged, thanks for contributing! Just have to push a release with this guy...

Could you show the error you were encountering, as well as the version of rubygems you are using?

I've used this for quite awhile now without issue.

Sorry, I forgot to includes the basic information :)
My machine Linux nibble 2.6.30-ARCH #1 SMP PREEMPT Mon Aug 17 16:06:45 CEST 2009 x86_64 AMD Turion(tm) X2 Dual-Core Mobile RM-72 AuthenticAMD GNU/Linux RubyGems v1.3.5 Ruby ruby 1.8.7 (2009-06-12 patchlevel 174) [x86_64-linux]

I found this error in my fork of the Gemcutter project. When I run rake install, nothing else returns. So, I used strace for discover the problem ... and read in trace output that the network down by timeout. The gem command not use the option '--remote' by default.

I had the same problem in other projects and rakefiles.

Fixed in f1bcf06. Thanks for reporting and tracking down the problem!

I took a quick look at your fork, and it seems to be in order. The only issues/edge cases I can think of is what would happen if you are currently on a prerelease, and then use version:bump:*.

I also wonder if there should be built in support for doing prerelease, like:

• rake version:bump:major:prerelease
• rake verison:bump:prerelease

The first could bump you to the next major release, and then add a prerelease version. The second could bump an existing prerelease by one.

Thoughts?

I intentionally made it clear out the pre-release if you use any of the version bumps, assuming that they will be manually managed (since you could in theory put anything in the pre-release/build slot). This also solves the need to 'bump' the pre-release version, explicit version writes could handle it.

WDYT?

That behavior seems about right.

I finally took a closer look at it, and the tests pass, but one of the features fails:

$ cucumber features/tasks/version_bumping.feature:35 -r featuresFeature: bumping version

  Scenario: arbitrary version with a build version                                                          # features/tasks/version_bumping.feature:35
    Given a working directory                                                                               # features/step_definitions/filesystem_steps.rb:1
    And I use the existing project "existing-project-with-version-yaml" as a template                       # features/step_definitions/filesystem_steps.rb:53
    And "VERSION.yml" contains hash "{ :major => 1, :minor => 5, :patch => 3}"                              # features/step_definitions/filesystem_steps.rb:58
    When I run "rake version:write MAJOR=3 MINOR=7 PATCH=1 BUILD=2" in "existing-project-with-version-yaml" # features/step_definitions/filesystem_steps.rb:25
    Then the process should exit cleanly                                                                    # features/step_definitions/filesystem_steps.rb:45
    And the updated version, 3.7.1.2, is displayed                                                          # features/step_definitions/filesystem_steps.rb:37
      <"(in /Users/nichoj/code/active/jeweler/tmp/existing-project-with-version-yaml)\nUpdated version: 3.7.1\n"> expected to be =~
      </Updated\ version:\ 3\.7\.1\.2/>. (Test::Unit::AssertionFailedError)
      /gentoo/usr/lib/ruby/1.8/test/unit/assertions.rb:48:in `assert_block'
      /gentoo/usr/lib/ruby/1.8/test/unit/assertions.rb:500:in `_wrap_assertion'
      /gentoo/usr/lib/ruby/1.8/test/unit/assertions.rb:46:in `assert_block'
      /gentoo/usr/lib/ruby/1.8/test/unit/assertions.rb:229:in `assert_match'
      /gentoo/usr/lib/ruby/1.8/test/unit/assertions.rb:495:in `_wrap_assertion'
      /gentoo/usr/lib/ruby/1.8/test/unit/assertions.rb:221:in `assert_match'
      ./features/step_definitions/filesystem_steps.rb:38:in `/^the updated version, (.*), is displayed$/'
      features/tasks/version_bumping.feature:41:in `And the updated version, 3.7.1.2, is displayed'

Failing Scenarios:
cucumber features/tasks/version_bumping.feature:35 # Scenario: arbitrary version with a build version

1 scenario (1 failed)
6 steps (1 failed, 5 passed)
0m1.674s

I did some testing by hand and was getting the same results.

Seems it's not actually using BUILD in Jeweler::Tasks or Jeweler#write_version yet.

Fear not, I finished typing in BUILD, as well as making sure that it works for plaintext in addition to YAML.

Merged in now. Thanks for getting the ball rolling.

Please run rake with --trace, and post the results.

This is a rubygems / ruby 1.9 issue, not a jeweler issue:

http://rubyforge.org/tracker/index.php?func=detail&aid=27087&group_id=126&atid=575

running rake with trace doesn't do anything since the errors are caught, and the rake -T output actually happens.

From @rsanheim's comments there does seem to be this backtrace:

http://runcoderun.com/rsanheim/ruby19_rubygems_bug/builds/65d60d3f7cf8ba5efa49933c02c4d5c2f9e999ba/1/ruby_191

I guess this could be very likely a bug in rubygems 1.3.5

Closing, since there's not a whole lot I can do on the jeweler side of things

This came up defunkt first released rip. We talked, and thought it was best to have lib/your-namespace/VERSION. Never saw anything of it though.

As for updating the VERSION constant at release time... that would work as well. Originally jeweler worked off a lib/your-namespace/version.rb, but it was pretty problematic to have to 1) determine what your top level namespace is (class, module, nested?) and 2) then write out the correct version.rb.

I'd be happy with something like this (not hard to do from my reading of the code):

Jeweler::Tasks.new(:version_path => "lib/VERSION", :version_format => :plaintext) do |gemspec|
  ...
end

I'm content to read that file to set my VERSION constant.

That seems appropriate. Although, you will probably want :version_path to be lib/your-namespace/VERSION, otherwise it'd make rip unhappy.

I'm here for the same reason @chriseppstein. I have a simpler proposal, why Jeweler simply don't allow us to set the version in the specification?

require File.dir(__FILE__) + "lib/my_project/version.rb"

Jeweler::Tasks.new do |s|
  s.version = MyProject::VERSION
  # more stuff
end

Simple and would do the trick for me. If the version is not set, we could go back and check for the yml file.

I can see how that makes sense.

However, it'd be quite a larger change to jeweler. I'm pretty sure the gemspec's version gets overriden in a lot of places, so you'd have to track whether or not that should happen. In addition, all the version bump related would need to be disabled somehow, since jeweler wouldn't be managing the version anymore.

I got that working with a few changes. :) We can move the version tasks to a module and include them if no version was set. I will try to provide a patch!

Here it goes:

http://github.com/josevalim/jeweler

It would be nice if you can merge it! :)

Regards!

Any news on this? :)

Been in launch mode for the day job for the last week, so hadn't really had time to work on jeweler.

At a glance, the patch looks pretty good. Now to just find some jeweler time...

Looked into this a little more, and it seems to work.

Only issue I could find is that rake version doesn't work correctly. There probably should be a cucumber story to cover that.

At a glance, this seems like it'd be sufficient:

class Jeweler
  def version
    @gemspec.version || @version_helper.to_s
  end
end

Yeah, it will work. I was only careful to not add rake version tasks if a version file does not exist.

Fixed and merged now. Just waiting on a new release...

Awesome! Thanks! :)

This is actually a ruby 1.9 bug in git (gem). Offending line:

Dir.chdir(@git_dir, &build_list)

Basically needing to pass a block/lambda to chdir. This must have changed in ruby 1.9...

This is fixed in git 1.2.4. Next release will require that version.

Hm.... --global must be from a more recent version of git.

Can you try upgrading to at least 1.6.2.x? If that works, I can update the git gem to complain about it, and make jeweler account for it.

I'm having this problem, even with git correctly configured:
http://gist.github.com/167340

pbalduino, that looks like a separate issue. so please open a new one, and include what version of git you are running (git --version)

I updated git to 1.6.4.msysgit.0 yesterday and it doesn't solve the problem.

Can you try running the git command directly?

ie: git config --global --list

If that doesn't work, can you take a look at git help config, and see if it mentions anything about 'global'?

git config --global --list works well.

What about the exact command git is doing? git config '--global' '--list'

http://gist.github.com/168023

Ok, this is mind boggling. I assume there's some disconnect between the git you are running from the command line, and what is being run in the git gem.

Maybe try something like this, while running irb -rgit:

puts Git::Lib.new(nil, nil).current_command_version

And compare it to git --version

puts Git::Lib.new(nil, nil).current_command_version throws this:

1
6
4

As I said:

$ git --version
git version 1.6.4.msysgit.0

Sorry if this is being a little tedious. Still not sure what the deal is.

What about the output from:

puts Git.global_config

?

Sorry if this is being a little tedious.

No problem ;)

$ cat gittest.rb
require "git"

puts Git.global_config

$ ruby gittest.rb

So, I'm kind of out of ideas. My best bet probably is to try to reprduce the problem on windows. Because of unrelated reasons, I recently had to install windows on a spare laptop, so I can try to reproduce...

Tracked this down. git gem issues command git config '--global' '--list' where parameters are quoted with ' and windows cannot handle these. Using double quotes fixes this. lib/git/lib.rb line 713

def escape(s)
  '"' + s.to_s.gsub('"', '\"') + '"'
end

It works, thanks!

I had to use this too--any chance of releasing the git gem again with this fix?
Thanks.
-r

Fixed in git 1.2.3, and master of jeweler.

That is to say, installing git 1.2.3 should fix the problem. jeweler master explicitly requires this version.

Thanks for doing that.

I'm not really inclined to add this just for the sake of compatibility with other libraries' rake tasks.

If someone runs rake gem, and see there's not a task, it's just a matter of rake -T to see what should be run to use the gem.

Additionally, if a gem author wishes it, they are easily able to add it to their own gem task that does just as you are looking for.

So, advantages: compatibility with the other 'n' gem generators; drawbacks: none. interesting...

I know. Crazy, right?

The short version is I don't think it's a significant enough advantage to really be bothered with. The much longer version...

There used to be a lot more aliases around for a bunch of the rake tasks. In the end, I decided to prune them down so that there was just a canonical way of doing them. So, not wanting to add extra tasks to be compatible with other gem management libraries is kind of in the same vain.

In addition, if I were to want to provide such task-level compatibility, I'd probably want to take a lot closer look at what tasks these other libraries provide. Do they all really have a 'gem' task which builds the gem? Are there any tasks they have that are of interest that jeweler doesn't? Are there any task name overlaps which aren't the same, or that behave different? And so on. For example, hoe has rake release VERSION=1.0.1. That's kinda different than the way jeweler works

I can confirm I had the same issue with an existing project. Installing the updated jeweler gem broke my existing rakefile as it could no longer see the rubyforge tasks and was unable to publish. Adding the following to my rakefile fixed the issue:

Jeweler::RubyforgeTasks.new do |rubyforge|
  rubyforge.doc_task = "rdoc"
end

Updated in 2d5b86f. Thanks for the catch.

Great. I did just notice that the formatting of these new instructions is a little messed up when viewing the README on GitHub. I think you need to indent the whole block of code for it to display properly. This happens in several places in the README. Cheers.

I have no idea why it's formating incorrectly. It's indented four spaces, like markdown expect, and like other places in the README do.

Yes, it does seem correct. I would file a bug with GitHub.

http://github.github.com/github-flavored-markdown/

http://daringfireball.net/projects/markdown/syntax#precode

Cheers.

I tried previewing it in TextMate, and it formatted incorrectly, so the problem probably isn't GitHub specific.

You should try removing therescue block in your Rakefile for jeweler, in order to see what the actual error is.

The problem seems to be that Jeweler requires a contrib file in Rake that Ruby 1.9 doesn't have anymore, namely rake/contrib/sshpublisher.

$ ruby -v
ruby 1.9.1p243 (2009-07-16 revision 24175) [i686-linux]

$ ruby
require 'jeweler'
^D
/usr/lib/ruby/gems/1.9.1/gems/technicalpickles-jeweler-1.2.1/lib/jeweler/rubyforge_tasks.rb:3:in `require': no such file to load -- rake/contrib/sshpublisher (LoadError)
    from /usr/lib/ruby/gems/1.9.1/gems/technicalpickles-jeweler-1.2.1/lib/jeweler/rubyforge_tasks.rb:3:in `<top (required)>'
    from /usr/lib/ruby/gems/1.9.1/gems/technicalpickles-jeweler-1.2.1/lib/jeweler.rb:17:in `require'
    from /usr/lib/ruby/gems/1.9.1/gems/technicalpickles-jeweler-1.2.1/lib/jeweler.rb:17:in `<top (required)>'
    from -:1:in `require'
    from -:1:in `<main>'

Rake is bundled with Ruby 1.9 now, but doesn't seem to have any contrib/ directory.

Have you tried installing the gem version of rake? I suspect that might fix the problem.

Yeah, it works the with the rake gem. Feels like a bit of a hack though.

It sounds like a dependency on rake should fix the problem in that case.

This task actually isn't being used anymore, so it should be fine on the next release.

Duly noted.

http://github.com/ddollar/jeweler/tree/gemcutter

Awesome, thanks!

It looks good from a cursory glance, but might be a couple of days before I have time to merge it in and release.

This was merged & released awhile back.

I suspect that the next jeweler release should fix this.

Trying to use Jeweler to roll my own Gem and I'm hitting this error, too.

One thing I've noticed is that running git config '--list' does list the contents of this file.

greg@greg:~/Sites/rails $ git config '--list'
github.user=grippy
github.token=

Either downgrade to git 1.1.1, or try using jeweler master, until a release happens.

Sounds good. Thanks for the help.

Just tried downgrading to the git 1.1.1 and I'm now getting:

No user.name found in ~/.gitconfig. Please tell git about yourself (see http://github.com/guides/tell-git-your-user-name-and-email-address for details). For example: git config --global user.name "mad voo"

I see this is already a bug filed with a different issue #.

I tried installing technicalpickles-jeweler via the gems.github.com repos and its the same version number as rubyforge. Is there a way to install the jeweler master as a gem?

Sorry if it's an obvious question, but have you previously set user.name globally? ie

git config --global user.name "my name"

1.1.0 released, hopefully fixing this.

Aha! Yes, I'm feeling rather noobish right now. Just signed up for github and have limited experience with git.

Here's where my confusion came from:

In your readme, it points to using the local github directions for setting the git global config variables (http://github.com/guides/local-github-config)

"Using to start a new project Jeweler provides a generator. It requires you to setup your name and email for git and your username and token for GitHub."

I mistook setting the following the global config variables for the ones required by Jeweler.

git config --global github.user name
git config --global github.token token

vs.

git config --global user.name "name"
git config --global user.email "email"

Note to self: RTFM! http://github.com/guides/tell-git-your-user-name-and-email-address

From what I cant tell, these variables are passed into the templates which generate the Rakefile. Is it possible to stub them until they're added to the ~/.gitconfig like "user" and "user@example.com"? (No reply is necessary. Just me thinking aloud.)

Just upped to the latest version and the generator brewed a delicious project. Can't wait to test it out.

Thanks for the help,
Greg

Ah, I barely changed ruby-git today to add that, in order to catch a number of issues that came up when using old (< 1.5) versions of git.

I think I can probably ignore the tiny version of git in practice.

Fixed in git 1.2.2 to deal with versions like 1.6.4. Thanks for picking up on this, because otherwise, I wouldn't have noticed until I upgraded (which I just did, incidentally).

Awesome dude. Love the gem!

Merged in the fix, thanks for contributing!

This commit is relevant: 49fb3b5

I mostly haven't merged this in because I try to avoid using the git command directly (favoring ruby-git which I do have commit access to).

Just committed and released a fix for this in 1.0.2. Thanks for bringing it to my attention!

b2bb316

You need to install shoulda: gem install thoughtbot-shoulda. I'm currently looking into a better way to manage test dependencies.

Committed a fix for this: 26d82ac

This is related to issue #19. It has to do with how ruby-git pulls out data from ~/.gitconfig. It does it own thing, instead of using git config directly.

I suspect that if you did git config user.email "Mister Dude", you'd see it update the entry to not have quotes.

I've released a fix to git that should address this. Expect a release of jeweler to use it in the next day or two.

1.1.0 released, hopefully fixing this.

Tracked the issue down further

[user]

name  = David Dollar
email = <ddollar@gmail.com>

The git gem does not like the double-space between "name" and "="

jeweler uses the git gem to look this up, and this is uncovering a bug there. I just pushed a version bump to git that should fix it though.

A release of jeweler that uses this updated git will be forthcoming.

I have a similar problem, but my git gem cant even find my ~/.gitconfig file. I get the following error, I beleve this is a probelm with the git gem, is it so?

/Library/Ruby/Gems/1.8/gems/git-1.2.2/lib/git/lib.rb:700:in `command': git config '--list' '--file' '~/.gitconfig' 2>&1:fatal: unable to read config file ~/.gitconfig: No such file or directory (Git::GitExecuteError)

That is unrelated, so please open a separate issue. The next release might fix that though.

1.1.0 released, hopefully fixing this.

Confirmed as fixed

Fixed: 048ab43

Thanks for reporting.

Good point. I suspect it's just a stale description. It's removed in master now. Thanks for reporting!

It also happens if you update your gemspec and commit the changes before calling rake release. Occasionally I update the gemspec myself but still want rake release to tag and push. Instead I get the following error:

  Committing siren.gemspec
  rake aborted!
  git commit '-m' 'Regenerated gemspec for version 0.1.1'  2>&1:# On branch master
  nothing to commit (working directory clean)

Basically it would be nice if it just skipped over the gemspec regeneration if nothing needs to happen (ie: gemspec is regenerated but there is nothing to commit).

Fixed in 899aabc

1.1.0 released, hopefully fixing this.

Merged in. Thanks for the contribution!

rubyforge:release failing because rubyforge_project in config is not used

Most of the time, your project is your gem name, so for most cases, it’s cool.

Just update your Rakefile to point where you want to be uploading too.

Because it’s not a jeweler task, it doesn’t actually have access to the gemspec, and hence, the rubyforge_project.

So, I did want to keep it flexible about where you upload files too (maybe you want root to be rdoc, maybe not), and I didn’t want to introduce any non-gemspec configuration, so I left this as hardcoded (but generated at least).

by Josh Nichols

This has been addressed by the new Jeweler::RubyforgeTasks that's in 1.0. Just add a line like this to your Rakefile:

Jeweler::RubyforgeTasks.new

Just committed a fix for this: f3a8cfc

1.1.0 released, hopefully fixing this.

rubyforge:release failing because no processor_id configured for

I’ll at least need a backtrace and a pointer to the source for the project to get an idea what is going on.

Make sure you’ve followed the notes in the README about doing rubyforge releases. In particular, there’s a rubyforge:setup task.

by Josh Nichols

rubyforge:release failing because no processor_id configured for

Yes, I did run the setup.
Ok, I hope this helps!
Thanks, and sorry for the trouble.

@@@ [15:24][~/backports(master)]$ rake rubyforge:setup (in /Users/work/backports) Logging into rubyforge
Creating backports package in the marcandre project
Updating marcandre
[15:41][~/backports(master)]$ rake rubyforge:release --trace (in /Users/work/backports) Invoke rubyforge:release (first_time) Invoke rubyforge:release:gem (first_time) Invoke gemspec (first_time) Invoke gemspec:generate (first_time) Invoke VERSION.yml (first_time, not_needed) Execute gemspec:generate Generated: backports.gemspec
Invoke gemspec:validate (first_time) Invoke VERSION.yml (not_needed) Execute gemspec:validate backports.gemspec is valid.
Execute gemspec Invoke build (first_time) Execute build Successfully built RubyGem Name: backports Version: 1.0.0 File: backports-1.0.0.gem ** Execute rubyforge:release:gem Logging in rubyforge
Releasing backports-1.0.0 to marcandre
rake aborted!
no <processor_id> configured for
/Library/Ruby/Gems/1.8/gems/rubyforge-1.0.3/lib/rubyforge.rb:409:in lookup’ /Library/Ruby/Gems/1.8/gems/rubyforge-1.0.3/lib/rubyforge.rb:281:inadd_release’ /Library/Ruby/Gems/1.8/gems/technicalpickles-jeweler-0.10.2/lib/jeweler/commands/release_to_rubyforge.rb:25:in run’ /Library/Ruby/Gems/1.8/gems/technicalpickles-jeweler-0.10.2/lib/jeweler.rb:119:inrelease_gem_to_rubyforge’ /Library/Ruby/Gems/1.8/gems/technicalpickles-jeweler-0.10.2/lib/jeweler/tasks.rb:94:in define’ /Library/Ruby/Gems/1.8/gems/rake-0.8.4/lib/rake.rb:617:incall’ /Library/Ruby/Gems/1.8/gems/rake-0.8.4/lib/rake.rb:617:in execute’ /Library/Ruby/Gems/1.8/gems/rake-0.8.4/lib/rake.rb:612:ineach’ /Library/Ruby/Gems/1.8/gems/rake-0.8.4/lib/rake.rb:612:in execute’ /Library/Ruby/Gems/1.8/gems/rake-0.8.4/lib/rake.rb:578:ininvoke_with_call_chain’ /System/Library/Frameworks/Ruby.framework/Versions/1.8/usr/lib/ruby/1.8/monitor.rb:242:in synchronize’ /Library/Ruby/Gems/1.8/gems/rake-0.8.4/lib/rake.rb:571:ininvoke_with_call_chain’ /Library/Ruby/Gems/1.8/gems/rake-0.8.4/lib/rake.rb:588:in invoke_prerequisites’ /Library/Ruby/Gems/1.8/gems/rake-0.8.4/lib/rake.rb:585:ineach’ /Library/Ruby/Gems/1.8/gems/rake-0.8.4/lib/rake.rb:585:in invoke_prerequisites’ /Library/Ruby/Gems/1.8/gems/rake-0.8.4/lib/rake.rb:577:ininvoke_with_call_chain’ /System/Library/Frameworks/Ruby.framework/Versions/1.8/usr/lib/ruby/1.8/monitor.rb:242:in synchronize’ /Library/Ruby/Gems/1.8/gems/rake-0.8.4/lib/rake.rb:571:ininvoke_with_call_chain’ /Library/Ruby/Gems/1.8/gems/rake-0.8.4/lib/rake.rb:564:in invoke’ /Library/Ruby/Gems/1.8/gems/rake-0.8.4/lib/rake.rb:2027:ininvoke_task’ /Library/Ruby/Gems/1.8/gems/rake-0.8.4/lib/rake.rb:2005:in top_level’ /Library/Ruby/Gems/1.8/gems/rake-0.8.4/lib/rake.rb:2005:ineach’ /Library/Ruby/Gems/1.8/gems/rake-0.8.4/lib/rake.rb:2005:in top_level’ /Library/Ruby/Gems/1.8/gems/rake-0.8.4/lib/rake.rb:2044:instandard_exception_handling’ /Library/Ruby/Gems/1.8/gems/rake-0.8.4/lib/rake.rb:1999:in top_level’ /Library/Ruby/Gems/1.8/gems/rake-0.8.4/lib/rake.rb:1977:inrun’ /Library/Ruby/Gems/1.8/gems/rake-0.8.4/lib/rake.rb:2044:in standard_exception_handling’ /Library/Ruby/Gems/1.8/gems/rake-0.8.4/lib/rake.rb:1974:inrun’ /Library/Ruby/Gems/1.8/gems/rake-0.8.4/bin/rake:31 /usr/bin/rake:19:in `load’ /usr/bin/rake:19 @@@

by Marc-André Lafortune

rubyforge:release failing because no processor_id configured for

My "~/.rubyforge/user-config.yml", in case that’s of any help:
@@@

uri: http://rubyforge.org
is_private: false
username: marcandre
cookie_jar: /Users/work/.rubyforge/cookie.dat
password: SomeNiftyPasswordHere
@@@

by Marc-André Lafortune

rubyforge:release failing because no processor_id configured for

OK, I found how to fix it, but not why I needed to fix it.

I modified the file ~/.rubyforge/autoconfig.yml from:

@@@ processor_ids: {}
@@@ to
@@@ processor_ids:
Any: 8000 @@@ I looked up at the source of the HTML page in rubyforge that let’s you select the processor to get that 8000 value.

So basically, this is not your fault but should be reported to whoever makes the rubyforge gem...

by Marc-André Lafortune

rubyforge:release failing because no processor_id configured for

Sorry for the zillions of emails & requests today! I’m done after this one, I promise! :-)

Just wanted to point out that after my successful release of my gem, ’rubyforge config’ now writes the full list of processor_ids to that auto_config file.

I remember doing ’rubyforge config’ as instructed, and again after the ’rake rubyforge:setup’ and getting ’Fetching 2 projects’. So probably this happens only to users with completely empty projects? Not sure.

Anyways, if someone is stuck with this, hopefully they’ll find this thread.

Thanks again!

by Marc-André Lafortune

rubyforge:release failing because no processor_id or release_id configured for

Hi!
I tried (a couple of times) releasing another gem (packable) to rubyforge and got an error:

@@@ [12:42][~/flvlib/packable(master)]$ rake rubyforge:release --trace (in /Users/work/flvlib/packable) Invoke rubyforge:release (first_time) Invoke rubyforge:release:gem (first_time) Invoke gemspec (first_time) Invoke gemspec:generate (first_time) Invoke VERSION.yml (first_time, not_needed) Execute gemspec:generate Generated: packable.gemspec
Invoke gemspec:validate (first_time) Invoke VERSION.yml (not_needed) Execute gemspec:validate packable.gemspec is valid.
Execute gemspec Invoke build (first_time) Execute build Successfully built RubyGem Name: packable Version: 1.2.0 File: packable-1.2.0.gem ** Execute rubyforge:release:gem Logging in rubyforge
Releasing packable-1.2.0 to marcandre
rake aborted!
Couldn’t get release_id, upload failed?
/usr/local/ruby191/lib/ruby/gems/1.9.1/gems/rubyforge-1.0.3/lib/rubyforge.rb:316:in add_release’ /usr/local/ruby191/lib/ruby/gems/1.9.1/gems/technicalpickles-jeweler-0.10.2/lib/jeweler/commands/release_to_rubyforge.rb:25:inrun’ /usr/local/ruby191/lib/ruby/gems/1.9.1/gems/technicalpickles-jeweler-0.10.2/lib/jeweler.rb:119:in release_gem_to_rubyforge’ /usr/local/ruby191/lib/ruby/gems/1.9.1/gems/technicalpickles-jeweler-0.10.2/lib/jeweler/tasks.rb:94:inblock (3 levels) in define’ /usr/local/ruby191/lib/ruby/gems/1.9.1/gems/rake-0.8.4/lib/rake.rb:617:in call’ /usr/local/ruby191/lib/ruby/gems/1.9.1/gems/rake-0.8.4/lib/rake.rb:617:inblock in execute’ /usr/local/ruby191/lib/ruby/gems/1.9.1/gems/rake-0.8.4/lib/rake.rb:612:in each’ /usr/local/ruby191/lib/ruby/gems/1.9.1/gems/rake-0.8.4/lib/rake.rb:612:inexecute’ /usr/local/ruby191/lib/ruby/gems/1.9.1/gems/rake-0.8.4/lib/rake.rb:578:in block in invoke_with_call_chain’ /usr/local/ruby191/lib/ruby/1.9.1/monitor.rb:190:inmon_synchronize’ /usr/local/ruby191/lib/ruby/gems/1.9.1/gems/rake-0.8.4/lib/rake.rb:571:in invoke_with_call_chain’ /usr/local/ruby191/lib/ruby/gems/1.9.1/gems/rake-0.8.4/lib/rake.rb:588:inblock in invoke_prerequisites’ /usr/local/ruby191/lib/ruby/gems/1.9.1/gems/rake-0.8.4/lib/rake.rb:585:in each’ /usr/local/ruby191/lib/ruby/gems/1.9.1/gems/rake-0.8.4/lib/rake.rb:585:ininvoke_prerequisites’ /usr/local/ruby191/lib/ruby/gems/1.9.1/gems/rake-0.8.4/lib/rake.rb:577:in block in invoke_with_call_chain’ /usr/local/ruby191/lib/ruby/1.9.1/monitor.rb:190:inmon_synchronize’ /usr/local/ruby191/lib/ruby/gems/1.9.1/gems/rake-0.8.4/lib/rake.rb:571:in invoke_with_call_chain’ /usr/local/ruby191/lib/ruby/gems/1.9.1/gems/rake-0.8.4/lib/rake.rb:564:ininvoke’ /usr/local/ruby191/lib/ruby/gems/1.9.1/gems/rake-0.8.4/lib/rake.rb:2027:in invoke_task’ /usr/local/ruby191/lib/ruby/gems/1.9.1/gems/rake-0.8.4/lib/rake.rb:2005:inblock (2 levels) in top_level’ /usr/local/ruby191/lib/ruby/gems/1.9.1/gems/rake-0.8.4/lib/rake.rb:2005:in each’ /usr/local/ruby191/lib/ruby/gems/1.9.1/gems/rake-0.8.4/lib/rake.rb:2005:inblock in top_level’ /usr/local/ruby191/lib/ruby/gems/1.9.1/gems/rake-0.8.4/lib/rake.rb:2044:in standard_exception_handling’ /usr/local/ruby191/lib/ruby/gems/1.9.1/gems/rake-0.8.4/lib/rake.rb:1999:intop_level’ /usr/local/ruby191/lib/ruby/gems/1.9.1/gems/rake-0.8.4/lib/rake.rb:1977:in block in run’ /usr/local/ruby191/lib/ruby/gems/1.9.1/gems/rake-0.8.4/lib/rake.rb:2044:instandard_exception_handling’ /usr/local/ruby191/lib/ruby/gems/1.9.1/gems/rake-0.8.4/lib/rake.rb:1974:in run’ /usr/local/ruby191/lib/ruby/gems/1.9.1/gems/rake-0.8.4/bin/rake:31:in’ /usr/bin/rake:19:in load’ /usr/bin/rake:19:in’ @@@

I opened the infamous ’autoconfig’ file and the release id parts looked like:

@@@ release_ids:
backports:

1.0.0: 32948

packable: {} @@@

That seems normal to me, since it’ll be the first release of ’packable’. Anyways, added a bogus release:

@@@ release_ids:
backports:

1.0.0: 32948

packable:

0.0.0: 12345

@@@

and then it worked. Again, I’m not sure if it’s jeweler (maybe) or rubyforge (more likely) that’s at fault here.

Thanks!

by Marc-André Lafortune

Guys, this is a problem with the rubyforge gem that I used to run into a lot..... See step #7 in this article: http://blog.bogojoker.com/category/rr/

For whatever reason, I don't get this error anymore, but I do think it's an issue with the rubyforge gem itself.

I'm not terribly surprised by it being something with rubyforge.

Maybe I should create a 'Rubyforge' wiki page, and include some notes there.

Closing, because I don't think there's much I can do about it in jeweler land. I've updated the dependency on rubyforge to be the latest 2.0.0, so hopefully that does it.

This was resolved awhile back Thanks for reporting.

Project creation failing (adding origin remote)

If you’re able to, I’d suggest upgrading git. I’m on 1.6.0.x, and it works.

If that does the trick, it’s a bug in ruby-git, and we can take a look at fixing that gem.

by Josh Nichols

Project creation failing (adding origin remote)

Yup, upgrading to Git 1.6.x did the trick. Thanks.

by Nick Plante

I ran into the same problem, running git 1.5.4.4 installed by macports (I think). I updated to 1.6.3.3 and the project was created without error. I've added a "Git 1.6.x required" note to the wiki home page.

I just released some changes to the git gem, which I'll be able to make use of to detect this more handily.

Release forthcoming...

1.1.0 released, hopefully fixing this.

This was fixed at some point.

Thanks man, appreciate it. Loving jeweler.

C extensions support

I’ve never made a gem with C extensions, hence the lack of support. Not opposed to adding support to jeweler, just not sure how to kick it off.

Patches, of course, are welcome.

by Josh Nichols

Going to mark this one as on hold or waiting for patches.

GitHub Pages - RDoc to Branch

GitHub pages is something I’ve really wanted, but implementation wise, it’s been pretty messy. It’s kind of annoying bringing files from one branch to another.

If its just rdoc is what you’re looking for, I’d check out http://rdocul.us/

by Josh Nichols

You can generate rdoc in your main branch and push the generated directory to gh-pages with grancher. Here's my thor task using it

I finally came around to writing a small Rake task that addresses that problem. Find it here.

Now that rdoc.info is around, it's a lot easier to setup a post-commit hook to make it generate your rdoc, and link to it, rather than having jeweler code do it.

Cross-platform compilation, gem creation

You can see my needs in the Rakefile at http://github.com/jgarber/redcloth/blob/83b838258ce1d8fb866fd28ff8db8492339628e9/Rakefile

by Jason Garber

Cross-platform compilation, gem creation

For some reason I didn’t get a notification email for this...

I don’t think I’d be able to support java or mingw, as I don’t use those platform.

From the looks of it, you mostly do checks of the platform, and add extra files depending. Since the Jeweler::Tasks takes a block, you should be able to add the same kind of logic.

The thing is, I can’t tell what parts are RedCloth specific (I see a lot of ragel), and what’s the platform specific.

by Josh Nichols

Marking this as patches wanted.

rspec template should require spec_helper differently

Looks like the ticket process clobbered the double underscores around the FILE in my ticket. Should be:

require File.expand_path(File.dirname(FILE) + ’/spec_helper’)

by MarioAquino

rspec template should require spec_helper differently

Awesome.

require File.expand_path(File.dirname(doubleunderscoreFILEdoubleunderscore) + ’/spec_helper’)

by MarioAquino

Fixed in master.

gem install issues

by Josh Nichols

I've since released ruby-git to rubyforge, and an updated jeweler.

I've added the 'raise' to the README, the project's Rakefile and to the template in this branch: http://github.com/retoo/jeweler/tree/better-error, if you like that approach feel free to merge it. If you want anything changed just tell me.

Cheers,
Reto

The correct thing to do is actually fix the dependency. That's done in the just released 0.11.1.

Raising on the error would kind of go against one of the main principles of jeweler, of not forcing itself on someone using the gem, unless they are specifically doing packaging/releasing stuff.

The API has changed subtly, such that every task almost always just a single call into Jeweler. If there are any stragglers, those probably can be moved into the corresponding Jeweler::Commands.

As a result, I don't think extracting it out into a separate module is particularly worthwhile.

CONFIG didn't work for me, but ENV did. Should add cygwin to the list aswell.

cmd_prefix = "sudo " if ENV['host_os'] =~ /mswin|windows|cygwin/i 

CONFIG should actually be Config::CONFIG, which gets defined when you require 'rbconfig'.

Fixed in 0e06397