make tests run locally without random gems

[grosser]

before: fun errors like this

rake
rake aborted!
LoadError: cannot load such file -- hoe

@drbrain

[drbrain]

I'm happy to add a Gemfile to make your development experience easier, but only as a change that is both minimal and maintainable.

The Gemfile duplicates the dependencies in the Rakefile. Instead add the hoe-bundler plugin (add Hoe.plugin :gemfile to the Rakefile) so the Gemfile can be regenerated from the authoritative source when it gets out of date.

Use rake bundler:gemfile to generate a Gemfile for commit (it will have a note about which file to edit when dependencies are added or updated.)

Please remove bundler/setup because it is using a derivative source of dependencies, and the changes to .travis.yml. They're not necessary as the tests pass as-is on Travis.

The Gemfile and Gemfile.lock shouldn't be shipped in the gem, so please remove them from Manifest.txt along with .bundle/config.

Also, since the Gemfile.lock should only exist at the root of the clone, please make it /Gemfile.lock in .gitignore, if it's popping up elsewhere in the file tree it should not be hidden.

[grosser]

• Can't remove from the manifest without breaking CI ... see stop shipping files end-users do not need #102 ... if other bogus files are ok to ship then so is a Gemfile ?
• It works "as is" if you know what gems it install first 🤷‍♂
• I'd love to use a more modern release flow with an actual gemspec/Gemfile/bundler instead of this 1-off hoe stuff rake release_to_gemcutter <- nice

[drbrain]

Can't remove from the manifest without breaking CI

Add an empty install: step to disable bundler on Travis and I think the Gemfile.lock won't appear and CI will pass with only adding Gemfile to Manifest.txt while I work out an update to hoe-travis and hoe-bundler.

It works "as is" if you know what gems it install first 🤷‍♂

You implied in #101 that you were comfortable reading the source, but now you are not?

Then the problem you are running into is that you are looking for documentation on how to get started, so we can fix it with documentation.

Changing the official release process to one that's lacking features I use to release this gem to fix a documentation problem is unacceptable.

When the "more modern" release flow has features matching hoe and its plugins I'll consider switching. Today it does not have those features. You can get started by adding a patch to bundler to use Gem::PackageTask so the gem can depend on rake file tasks as this is a key feature I require for other projects.

[grosser]

Updated

I'm not interested in learning hoe / reading docs on it, since I'm not trying to use it in the future.

This works to add prerequisites to tasks and should work for bundler release task

task(:foo) { puts "FOO" }
task(:bar) { puts "BAR" }
Rake::Task[:foo].prerequisites << :bar

[drbrain]

This works to add prerequisites to tasks and should work for bundler release task

Providing me with workarounds for a defective tool is not convincing me to use it

[grosser]

it's not a workaround, it's how rake tasks are used 🤷‍♂
same as task foo: [:bar]

[grosser]

alls clean now I hope

[grosser]

@drbrain good to go ?

[drbrain]

PS: I might know a little about rake tasks and how best to use them as I have been rake maintainer. Bundler is using them incorrectly and I won't consider using it until it's fixed. Stop trying to argue with me on this, it's not endearing.

[grosser]

I did not know you have a backstory with rake ... I used prerequisites a lot and it was stable so far 🤷‍♂