This patch looks good based on my informal local testing. Really nice work.

http://github.com/defunkt/rip/commit/308e9df23721d3f28ef54f33759218374c0d748a

My bad. I had a stray tab on the last line of my deps file. Totally works fine if the last line is completely blank which is all I care about.

Dunno if adding this extra code is worth it.

I think 'not blowing up' would be the right behaviour here, so adding the check in seems good to me. Rip should at least be able to gracefully skip over malformed contents of ripfiles.

As a tangent, if we're checking for lines to ignore, we could allow some form of comment line in .rip files too - any line starting with #, maybe? I don't know if that's useful at all, but it's certainly a possibility.

Great idea. Supporting comments would be really useful.

Patch: ignore comments in ripfiles
http://github.com/josh/rip/commit/3a552f3449c6ba77670729839b9a7660bc17a4a7

http://github.com/defunkt/rip/commit/3a552f3449c6ba77670729839b9a7660bc17a4a7

Disaster averted - installing from Git works. This appears gem related.

I'll look into this

I believe this is fixed here

+1 to this patch, too.

Brilliant! Merged in, thanks.

This is as of 4c2e0a8 (defunkt/master).

I hope this isn't because of the changes to PackageManager#add_package that I made for gems... hmm.

MetaPackages should not be passed to #add_package - why do remote gems need to? Is there another way to accomplish what they need?

I think every package gets passed to #add_package - there doesn't seem to be any logic in Installer#install that says otherwise.

That said, I'm not sure that my changes have caused the behaviour jmhodges is describing. I'll try to get to the bottom of it this weekend though.

It used to not install meta_packages - see http://github.com/defunkt/rip/commit/f029c292c46698a8f632af8e6397b2d176015c4c

Apologies for that - I must've accidentally removed that line when trying to get dependencies to work.

I believe that adding it back in fixes this, and #70; see here

+1 on that fix.

 →  rip install deps.rip 
 Successfully installed sinatra (3b992ad)
 Successfully installed cassandra_object (917c263)

 →  echo 'erubis' >> deps.rip 

 →  rip install deps.rip 
 rip: already installed sinatra (3b992ad)
 rip: already installed cassandra_object (917c263)
 Successfully installed abstract (1.0.0)
 Successfully installed erubis (2.6.5)

Thanks for the fix - merged and pushed!

Thanks, I'll take a look asap!

should this issue be closed?

Fixed in latest git!

Yes, thanks a lot.

I think this might be the gem server not responding withing 5 seconds (which is the internal timeout used), but I'm not sure...

Initially, I thought so too. But the weird thing is that, when I retry - it says gem x installed successfully. It might not be a big deal since it has always worked on the second try.

Just for interest, the next time it fails, take a look at what's in your ~/.rip/rip-packages directory. How much was successfully downloaded? Typically with a gem, you end up with three similarly-named files - a directory with a .gem in it, then a .gem file, and then a directory containing the unpacked gem.

When it fails, has all of that been created?

This should be fixed with lazyatom's timeout changes. Cheers.

I just did a test port of all gems to rip and it worked awesome. Great job gang.

What version of Ruby and OS are you using?

ruby -v:
ruby 1.8.6 (2008-08-11 patchlevel 287) [universal-darwin9.0]

Mac OS X 10.5.7

I'm getting a similar behavior on a similar configuration. These tests fail on f375cf0 reflecting the problem.

$ ruby --version
ruby 1.8.6 (2008-08-11 patchlevel 287) [universal-darwin9.0]

$ rip list
ripenv: ripdev

fakefs (99880ea)
test-spec-mini.rb (2009-07-23)

$ ruby test/git_test.rb
Loaded suite test/git_test
Started
.E.EE
Finished in 0.502716 seconds.

  1) Error:
test_fails_on_an_unknown_version():
Errno::ENOENT: No such file or directory - /Users/carl/Projects/rip/test/ripdir/rip-packages/simple_c-156d7c2b9cfa0bab0ee4a6f118998e17
    /Users/carl/.rip/active/lib/fakefs.rb:338:in `chdir'
    /Users/carl/.rip/active/lib/fakefs.rb:256:in `chdir'
    /Users/carl/Projects/rip/lib/rip/packages/git_package.rb:62:in `remote_exists?'
    /Users/carl/Projects/rip/lib/rip/packages/git_package.rb:26:in `exists?'
    /Users/carl/Projects/rip/lib/rip/installer.rb:17:in `install'
    /Users/carl/Projects/rip/lib/rip/commands/install.rb:34:in `install'
    test/git_test.rb:21:in `test_fails_on_an_unknown_version'

  2) Error:
test_works_with_a_real_version():
Errno::ENOENT: No such file or directory - /Users/carl/Projects/rip/test/ripdir/rip-packages/simple_c-156d7c2b9cfa0bab0ee4a6f118998e17
    /Users/carl/.rip/active/lib/fakefs.rb:338:in `chdir'
    /Users/carl/.rip/active/lib/fakefs.rb:256:in `chdir'
    /Users/carl/Projects/rip/lib/rip/packages/git_package.rb:62:in `remote_exists?'
    /Users/carl/Projects/rip/lib/rip/packages/git_package.rb:26:in `exists?'
    /Users/carl/Projects/rip/lib/rip/installer.rb:17:in `install'
    /Users/carl/Projects/rip/lib/rip/commands/install.rb:34:in `install'
    test/git_test.rb:26:in `test_works_with_a_real_version'

  3) Error:
test_works_with_an_existing_sha():
Errno::ENOENT: No such file or directory - /Users/carl/Projects/rip/test/ripdir/rip-packages/simple_c-156d7c2b9cfa0bab0ee4a6f118998e17
    /Users/carl/.rip/active/lib/fakefs.rb:338:in `chdir'
    /Users/carl/.rip/active/lib/fakefs.rb:256:in `chdir'
    /Users/carl/Projects/rip/lib/rip/packages/git_package.rb:62:in `remote_exists?'
    /Users/carl/Projects/rip/lib/rip/packages/git_package.rb:26:in `exists?'
    /Users/carl/Projects/rip/lib/rip/installer.rb:17:in `install'
    /Users/carl/Projects/rip/lib/rip/commands/install.rb:34:in `install'
    test/git_test.rb:32:in `test_works_with_an_existing_sha'

5 tests, 2 assertions, 0 failures, 3 errors

check those with defunkt - he mentioned having checked in some failing tests to do with git :/

mind you, that was with edge, not with 0.0.2

What version of rip are you guys running?

$ rip install git://github.com/defunkt/grit.git v1.1.1b
Successfully installed diff-lcs (491fbc0)
Successfully installed mime-types (v1.16)
Successfully installed grit (v1.1.1b)
$ rip --version
Rip 0.0.2

I'm aware of the broken tests on edge.

Running a clean install of 0.0.2:

$ sudo gem install rip
Building native extensions.  This could take a while...
****************************************************
So far so good...

Rip needs certain env variables to run. We've tried
to install them automatically but may have failed.

Run `rip check` to check the status of your
installation.

Get started: `rip -h` or http://hellorip.com/

****************************************************
Successfully installed rip-0.0.2
1 gem installed
$ rip env create grit
ripenv: created grit
$ rip install git://github.com/defunkt/grit.git v1.1.1b
rip: install failed
-> No such file or directory - /Users/carl/.rip/rip-packages/grit-1dce6a545b29fd1845f9dc123ead7fa8
$ rip --version
Rip 0.0.2

I also get the same test failures on this version.

MAC46SE ~: rip --version
Rip 0.0.2

Fix the "directory not found" error when installing git packages. Closed by 2cd750f

I noticed this too. What should Rip do if you are trying to override files it already knows about?

The install should fail, right?

I commited some stuff that might help with this in lazyatom@a2aefb3.

Presumably when installing a package, if any path in the files list already exists in an install package's files, we can raise an error, right?

OK, here's a quick attempt: lazyatom@14f75b923. I've pasted some sample output in this gist.

The only problem I can see is that I do still want to be able to play around with monk (in this case), so it should be possible to overcome this somehow. I think this is only really going to be an issue with github vs. normal gems, where the source name is different but the package is basically the same...

I'm not sure this works:

http://gist.github.com/168928

Hmm, I can't replicate that - here's what I get: http://gist.github.com/169000

I have been testing the gem stuff by blowing away ~/.rip/rip-packages, but in this instance I tried to follow your failing scenario exactly. Any ideas as to what's different?

I've included a minor diff (that I've since pushed) in the gist, but I don't think that would make a difference...

Okay the newest changes leave me in a better state: http://gist.github.com/169197

But should the whole install fail, or just the install of the conflicting package? I guess this way makes sense.

Okay merged, awesomeness.

Yeah, it's tricky. I'm really not sure what state is most useful for the user in the end :-/

At first the current behavior surprised me, but it makes the most sense: it's the fault of the gem author, not me. By not rolling back everything you give me (the Rip user) the power to fix the mistake.

What version of Rip are you using?

I get something similar:

→ rip list
rip: plugin not loaded (/Users/chris/.rip/active/lib/rip/commands/app.rb)
-> no such file to load -- rack

ripenv: nak

rip-server (864e87b)
sinatra (8c666fb)

Works now. Cheers.

Here's a patch for this: cldwalker@1afdc0f

Word. Merged in as d22be3a

Hooray. Thanks everybody.

This is a duplicate of issue #1

Closing dupe

I believe I've fixed this in lazyatom@910a61bf; you should now be able to supply versions on the command line, or in deps.rip.

I've implemented this in a better way in lazyatom@f7c08fb02, which is based off the more recent defunkt/master

Merged!

You can do this by passing either --bindir and/or --libdir to Rip's ruby setup.rb.

rip check does not work. Additionaly it only works when I'm installing by setup.rb not when I install it by gem.

What do you envision the API for this as looking like?

FYI, you can just put the file somewhere in ~/.rip and modify it from there. I do that often for both Rip packages and Rubygems.

I have a fix here: nakajima/rip@d7610f9

Merged!

Not sure how I made a duplicate.

There's always Ripe:
Ruby's Intelligent Packaging Environment

Since we're Ripe for change. Ripe with excitement. Ripe with anticipation. Ripe with perspiration ;)

http://skitch.com/defunkt/biykd

Seems okay to me :)

This was because my version of Grit was loading RubyGems. I've pushed a fix, sorry about that.

I've modified rip setup to accept a file.

So just run rip setup ~/.bashrc or whatever you need!

Maybe have it check whether the user has permissions to use the Dir, before telling them they have to.

The merged commits should now let you define the install dirs, the gem and rake used etc. Can you check if this solves the issue?

Works fine now, thanks.

When using Rip's setup.rb you can now pass --bindir. Thanks!

I can confirm this.

Strange, its not even on http://master.mirror.rubyforge.org/gems/ I wonder what's up.

This is affecting more then just rip. Almost all rubyforge mirrors are screwed up atm.

Looks like it was a Rubyforge fluke.

don't memoize actual_package in HTTPPackage. closed by 2ce50a8

Merged, thanks.

I got the same results by re-working Rip::Commands.parse_args [my solution treats -h and --help as options[:h] and options[:help], which seems more intuitive but may well break something :) ]

http://gist.github.com/129239

I like that better. Seems cleaner and more correct to me.

Thanks - I thought so too. Didn't have time to write a test, but it works for me.

Alright, merged in Ryan's patch then James'. Thanks guys.

rip build is the attempt to do what you describe.

http://github.com/defunkt/rip/blob/90ff5837d1aeda2d26f3a1e1b52493fd37b83feb/lib/rip/commands/build.rb

woot! thank you very much

This should be solved by adding a rip setup uninstall command that removes Rip by running Rip::Setup.uninstall.

/usr/local/bin/rip is not the only file Rip installs and therefor needs to remove.

We've added rip uninstall rip as the defacto way to uninstall rip moving forward.

What's your OS?

osx 10.5.7

no problems whatsoever on debian etch

Did you have /usr/local/bin in your $PATH prior to creating it?

Same issue, Mac OS X 10.5.7 Macports Ruby 1.8.7.

Tried removing /usr/local/bin from my $PATH, did not work
Created /usr/local/bin, worked

$PATH = /opt/local/bin:/opt/local/sbin:/usr/bin:/bin:/usr/sbin:/sbin:/usr/X11/bin:/Users/steve/.home/bin

Okay, we're using /usr/bin by default now as of ab5e4c8b1.

If anyone wants to take a stab at this I'd accept the patch.

This is addressed by rue/rip/commits/ac20d025, revised from earlier version.

sorta...having a namespaced standard like rubygems has, including provisions for multiple ruby versions seems like it would make more sense than adhoc installs. especially true for package maintainers (macports, apt, pkg, etc)

Haml has a VERSION at the root level because they use Jeweler.

I've talked to technicalpickles and future versions of Jeweler will be using lib/package/VERSION. A migration script will be provided.

I think this can be solved on a case by case basis - for instance, it's much easier for Haml to move the VERSION into lib/haml than it is for us to add code to Rip.

On that note, feel free to fork Haml and send them a pull request - I'm sure they'd happily accept it :)

I actually don't think that haml uses Jeweler. They just seem to be using their own VERSION file. Same idea, though.

Anyhow, I know this is a pretty small change for most libraries, but it might be a bigger problem (as a whole) to get every library out there to conform to the new rule* than it will be to implement something in rip that is compatible with existing libraries. And I really hope that rip is eventually compatible with everything, because I really want to use it.

* only put stuff you need at runtime in bin and lib

For completeness, note that Rails is in this camp, too. It depends on fresh_rakefile, README, configs/, doc/, environments/, helpers/ and html/ existing next to bin/ and lib/.

... and I totally meant to submit that as me, not @rubaidh!

At a guess, my ~/.bashblah isn't ... conventional?

For clarity, this doesn't affect macports ruby 1.8.7.

@mathie: dump the contents of /Library/Ruby/Gems/1.8/gems/rip-0.0.1/ext/gem_make.out here, please.

This should be fixed by b13f3685bd65, can you verify?

I am still getting this error on my system as well

I installed rip today on my Mac OS X machine. Version is 10.5.7. Xcode is the latest version as of today. Ruby and gem were my own builds. I also ran the /usr/bin versions of Ruby and gem and had no problems.

Umm, I suck. I failed to verify this before, err, installing a more recent version of Mac OS X on my laptop. FWIW, it installs correctly on a, err, more recent version of Mac OS X. :-)

Sweet, thanks.

Writing a patch...there is also some use of the rc file's contents rather than just checking the env which seems silly, is there a reason?

The main reason for this is I don't want Rubygems to install the rip binary because then every time you run rip it'll load the Rubygems runtime.

Perhaps we should install, as you suggest, a simple rip-setup script through Rubygems that does what it needs to do.

As far as checking ENV['blah'], that's a great idea.

Is this version workable?

http://github.com/rue/rip/commit/46bac5fca0ca7fadef620ee6b87e48f9d5c2f59b

installed with Rue's "rip setup" and got an "all systems go" :)

Closed by 90ff583

Could we drop "export RIPDIR=~/.rip" in the install script?

There's not.

Please re-open if I'm wrong.

What's wrong with calling ENV["RIPDIR"] = RIPDIR after setup appends to the bash script? Curious why that wouldn't work?

Try it. It does not work.

This is a feature of Unix. Subprocesses have no access to the parent process's environment.

fix: http://github.com/technoweenie/rip/commit/6530d5e55dd1ff5110ae44081b1528132e437e2b

Merged, thanks!

Don't display "requested by" if no one requested it before. Closed by 7f36172

Added in the form of the rip ruby command in 72d497f by codahale

done and done

yeah yeah we get it

yeah yeah we get it

Do you mean package install tests or rip install tests?

rip install tests. Package install tests should be covered by the package's test, I think.

Closing, we all know tests are needed

Super basic start here: nakajima/rip@c4c4e6d

Great, closing this as It Has Begun.

closing spam tickets

bye

This is coming as part of the remote gem dependency code I'm writing.

Great, closing this out for now.

Basic coverage here: http://github.com/defunkt/rip/blob/3e27d7d087aa5a7038312c87ccec687294bc1424/test/file_test.rb

woot.

Lookin' passable. Passable.

This'll clear out all the crap in the test output and let us actually run the tests without nasty aborts ruining our fun.

See nakajima/rip@b9a688d through nakajima/rip@7dfeab1.

Great, merged in.

Boom.

sha boom sha booms

http://hellorip.com/

So this is predicated on the idea that we keep the list of which versions we have installed somewhere or have some way of easily reproducing that list. I'm ka-thunking on the best way of doing that.

One idea is just have the .rip file updated on every install and uninstall. I think that's probably what I'm going to go with but I want to sleep on it.

We already keep and update the versions.

https://github.com/defunkt/rip/blob/69daedab81e0715378853372a67e3a12320e7624/lib/rip/package_manager.rb#L40-42

Doh, this is already done:

rip freeze ENV

Way to go, us.

Basic support was added for this tonight in the form of RemoteGemPackage.

You can now rip install ambition.

I think this is now covered, either by the source list in your current master, or by my branch which defaults to whatever sources the user already has for gems.

I can take this one if nobody has any objections.

Go for it!

Submitted for your approval:

https://github.com/nakajima/rip/commit/4cc3c7a948cbc7c9a7fe80d311b6f1ec0f92a43f

Do we want to also recognize things like "ambition-1" and "ambition-2" as versions 1 and 2 respectively? It seems a bit sketchy, but I thought I'd mention it anyway.

Sweet, merged in.

Maybe the capture should be -(\d+.)+ ?

I updated the capture:

https://github.com/nakajima/rip/commit/83080eb33bb6717f26bcd483193bdc00f0935df3

Awesomeness. Closing.

Working my way through the rubygems codebase to figure out the right places to mock out. I will be playing music in celebration when I do.

Here's a simple version which downloads dependencies: cldwalker@625d2bd
It doesn't uninstall dependencies or respect gem versions yet.

@cldwalker - That's awesome! If you can add some tests I'll merge it in so others may build on it?

Sure. I'll check it out when I get some free time.

I've added another approach, starting at this commit: lazyatom@f029c29

This is heavily based on cldwalker's work, but refactored to ensure that rip's internal dependency information is kept in sync. Let me know what you think; I'll be trying to use it, and updating accordingly.

This is freaking sweet and this is freaking merged.

So awesome, merged in.