it's kinda hard to tell without a full backtrace. It's a little suspect that the file is version.yml instead of VERSION.yml. Also, what version of jeweler are you using?

Would it have a problem with a lowercase file vs uppercase?

I update pretty frequently, so I usually have the latest version of jeweler.

Yeah, I kinda suspect that'd be a problem since everywhere in the code refers to VERSION.yml. Did it get renamed at some point or something?

Can you please elaborate on the type of errors you were running into?

Not sure if it's just the formating, but I'm exactly sure of all the things you're suggesting.

rake aborted!
Don't know how to build task 'rdoc'

is what i am getting when i dont have a rdoc task, and if i dont have a rdoc directory

total size is 0 speedup is 0.00
rsync error: some files/attrs were not transferred (see previous errors) (code 23) at main.c(1058) [sender=3.0.5]
rake aborted!
Command failed with status (23): [rsync -av --delete rdoc/ grosser@rubyforge...]

so i needed to add rdoc task, and add an rdoc directory

atm im doing:

# fake task so that rubyforge:release works task :rdoc do

`mkdir rdoc`
`echo documentation is at http://github.com/grosser/#{project_name} > rdoc/README.rdoc`

end

Thanks for clarifying.

So, it probably makes more sense to not attempt to publish docs to rubyforge if you don't have a related docs task.

This is actually configurable:

Jeweler::RubyforgeTasks.new do |rubyforge|
  rubyforge.doc_task = :some_task
end

This could be updated such a way to allow you to set it to false, or :none, or something like that, so it doesn't attempt to publish in that case.

why not do something like:

task = Rake::Task[doc_task] rescue puts('could not find #{doc_task}...') #dont crash when task is not defined
task.invoke if task

I don't know, I think I'd rather have it be a little more explicit and fail until you tell it not to do anything.

thats ok as long as it can be turned off(as you already said), i just do not like the fact that something that is not necessary lets the release process fail, and poor users have to figure out why, therefore id opt for a warning

No, I hadn't considered, because I don't use local gem repositories.

I don't see this as something I'd implement myself, but if there was a fork... and it followed the same paradigms for releasing, well maybe a merge might happen.

Merged.

I'd also like to see more proper thor support. I started using your Thorfile in thor as an example, but I'm not sure how you're actually supposed to run it. You can see it in the 'thor' branch.

Thor uses the name of the class as namespace, so you should run the gemspec task as:

thor default:gemspec

However, the default namespace can be a shortcut, so you need just do:

thor :gemspec

If that doesn't work, I will take a look at it when I'm back home. Also, you don't need the require 'spec/rake/spectask' at the top. :)

Thanks!

Ok, the comment above was done by @josevalim. ;)

I think you mean it does a require of 'reek/rake_task', not 'rake/testtask', right?

That being the case, I'm not sure what could be done to fix this. Sure, the generator can be fixed, but there's some people that would have generated their project already and have the old require.

Yes, sorry, I don't know why I didn't do a copy/paste...

I think you could support both versions in the generator (by rescuing the LoadError exception and retrying with the other path).

For the problem of already generated projets, I think it's really another bug: one should be able to update its jeweler-generated Rakefile to get modifications of the template, or even add new targets (for example someone should be able to add the reek target if the project was generated without it).

Doing a begin/rescue within a begin/rescue to support both requires seems a little messy.

Considering this is a generator, I think it'd make sense to go with the most recent version, and just make sure the error message tells you to install the specific version that starts using the different task require.

A non-jeweler specific fix would be to patch reek to put back the old file, and do a deprecation warning.

Fixed in cee2d7c, thanks for reporting!

any possibility for mkrf_conf.rb love in there, as well?
Thanks!

I don't even know what you mean... As far as I can tell, gem only cares about extconf.rb.

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 :-).

I'm assuming your talking in the context of running rake install?

I haven't used jruby at all, so I'm not really sure what the deal is

I do know that jeweler itself doesn't have anything to do with RUBY_HOME, so I'd guess that's something in gem.

As for sudo, that's being taken up in a separate issue, #51.

So, I'm not opposed to seeing bundler support (in fact, would like to see it).

However, I don't particularly like it placing gems into bin/. I just feel like that'd have some annoyances, like you'd have to start git ignoring stuff in bin, except for things that you'd want distributed, in addition to specifying them in gem.executables.

Perhaps bundler can be configured where it places the binaries?

This is possible.

# Specify where gem executables should be copied to.
#
# This is an optional setting.
# The default is: bin
bin_path "my/executables"

That's good. So, I'd think it's make sense to have them in bin/vendor, vendor/bin, something along those lines. That mean...

• The generator creates Gemfile
• Gemfile species a path for the executables that not in bin
• gitignores this path

yeah. ill fork and implement.

I went with the following:

--bundler flag to the generator

use ./gbin for the bundled gem path

add both ./vendor and ./gbin to .gitignore.

Commits viewable on: http://github.com/jsmestad/jeweler/tree/bundler_support

I've thought about it a little and I'm trying to figure out the use case for using this.

Is it for managing dependencies of a gem? If so, you'd still need need to manage those in the gemspec.

It makes it easy to fork a gem and just run ./bin/rake spec after doing gem bundle. Also the Gemfile manages all your gem dependencies at the same time. I added a rake hook that sets up the gemspec dependencies as well: http://github.com/jsmestad/jeweler/blob/bundler_support/lib/jeweler/templates/jeweler_tasks.erb#L13

The page in question is at http://wiki.github.com/technicalpickles/jeweler/customizing-your-projects-gem-specification for reference.

Will take a look at it soon.