Every repository with this icon (
) is private.
Every repository with this icon (
) is public.
| Description: | Ruby's Intelligent Packaging edit |
-
WARNING: Installing to ~/.gem since /opt/local/lib/ruby/gems/1.8 and
/opt/local/bin aren't both writable.Building native extensions. This could take a while...
ERROR: Error installing rip:
ERROR: Failed to build gem native extension./opt/local/bin/ruby extconf.rb rip: installing library files
rip: access denied. please try running again withsudoGem files will remain installed in /Users/user/.gem/ruby/1.8/gems/rip-0.0.3 for inspection.
Results logged to /Users/user/.gem/ruby/1.8/gems/rip-0.0.3/ext/gem_make.out
Comments
-
But good news -- it's not your fault: http://jira.codehaus.org/browse/JRUBY-3761
There may be a work-around for this, though.
Comments
Ha, I opened a ticket for this a few months back, but didn't include a test case so they closed it. Thanks for following through.
-
I was trying to build my version of the GeoIP lib (found at http://github.com/mtodd/geoip) which requires I provide additional build options. I usually build like so:
env ARCHFLAGS="-arch i386" make --with-GeoIP-dir=/opt/GeoIP/
and installing the gem is like:
sudo env ARCHFLAGS="-arch i386" gem install mtodd-geoip -s http://gems.github.com/ -- --with-GeoIP-dir=/opt/GeoIP/
Unfortunately, I was not able to pass in the additional --with-GeoIP-dir option when running rip build.
This needs to be either documented or support added. I did not look into the current state of its support.
Comments
Were you trying to install this as a gem or as a Git package, e.g.
rip install git://github.com/mtodd/geoip.git?I'm almost 100% sure I used:
@rip install git://github.com/mtodd/geoip.git@
but it's been some time and I can't recall exactly. I'll update my Rip install and try again later today.
rip installautomatically runsrip buildnow, but it doesn't pass along any flags. If that's what you need I'll add it, tho - I just need a testbed and the flags to pass.Unfortunately, building the GeoIP library isn't exactly trivial; if you look at the README at http://github.com/mtodd/geoip you'll see that you also need to build and install the C GeoIP library before building the library, but it gives you step-by-step directions.
Let me know if I can help or if you need me to test something.
-
3 votes
Publish Package URL Convention For SCMs (hg+http:// etc.?)
3 comments Created 6 months ago by rueSince some SCMs do not provide any clues to their identity in the URL alone, pip's example of
scm+proto(e.g.hg+http,cvs+sshetc.) is probably the simplest way to handle the situation (another suggested method is a --vcs flag, but it seems substandard, in particular because the full URL can be distributed as a single unit (URL schemes may contain +, in case someone is wondering.))Whichever mechanism chosen, it should be prominently publicised in the API and docs to avoid issues with adoption and Packages for the various other SCMs. (That is, I did not see a mention of this when I was looking.)
Comments
Yeah, this seems appropriate. Extensible to rubygems etc. if need be.
I found a link to the Pip scm url docs (for reference).
http://pip.openplans.org/requirement-format.html#version-control
-
1 vote
Inferring versions for FilePackage and DirPackage doesn't permit version conflicts
0 comments Created 6 months ago by nakajimaThe versions are part of the filenames, but we also derive the package name from the filenames. As a result, packages with inferred versions will never see conflict errors.
Also, do we want to be installing
foo-1.2.3.rbinto the libpath, or justfoo.rb, leaving the version out? I think I'd prefer the latter, since requiringfoo.rbis nicer, though it seems a bit dangerous.If we want to strip the version from the names, I have a patch here: nakajima/rip@4227a96
Otherwise, we may want to rethink this feature.
Comments
-
Something similar to
git reflogthat records every action you take in Rip.Comments
I have something basic working over at amerine/rip@a2aff21
Now I just need to work on giving a use the ability to traverse back and forth through the history somehow.
-
Where's the doc?
I'll take this one. Can't tag myself with it anymore it seems though.
Comments
Getting started: http://github.com/nakajima/rip-server
I've done a tiny bit of hacking on nakajima's code, found at http://github.com/mtodd/rip-server
Now can dynamically generate (though with shitty RDoc options) and display the RDoc files.
Was thinking of supporting a doc.rip file (similar to deps.rip) which would provide options to the RDoc generator (at the very least).
Thoughts?
-
1 vote
2 comments Created 6 months ago by aredridelawaiting patchxAbility to activate environments by absolute path would be great.featurex -
0 votes
4 comments Created 5 months ago by mloughranawaiting patchxProgramatically specify rip environment without symlinkingfeaturexI might be missing it, but I don't see a nice way to programatically specify an environment in the code. I first assumed that
Rip::Env.use('env')would achieve what I wanted, but that creates a symlink to active...This is a simplified version of what I'm thinking:
require 'rip' Rip.use_env('foo') class Rip def self.use_env(env) $:.unshift(File.expand_path(File.join('~', '.rip', env, 'lib'))) end endDoes this fit?
Comments
You can accomplish this with the
rip rubycommand.rip ruby ENV file.rbThat's certainly useful, but I was more thinking of scenarios where you don't invoke ruby directly. For example passenger
config.rufiles.If someone creates a patch for this I'll look at it. It's not something I would use yet.
-
0 votes
7 comments Created 5 months ago by luislavenaReplace symlinking of active environment with configuration filewindowsxHey Guys,
So far, RIP is great, but found that symlink options leaves Windows outside of the equation.
RIP and it's tweaks to RUBYLIB and RUBYOPT can be handled by Windows, but not symlinking for active configuration.
Could you guys consider in the future move from the symlinking way to a plain text file that contains active environment instead?
Thank you.
Comments
Can you elaborate on the plaintext file idea? I'd love to explore it but I'm not sure how it would work.
Guessing here, but I suspect Luis may have been thinking along the lines of git's .git/HEAD file or XFCE's .desktop launcher config files.
Could $RIPDIR/active be file containing a "reference" (ala .get/HEAD) to the active environment and used as a source of base path prefix for commands?
I don't really know that much about Windows, but in Unix you can't manipulate a shell's environment variables from a process. So there's no way to change Ruby's load path from a script or program.
This is why we use a symlink: we add the symlink to the load path and never have to worry about changing the load path on the fly (because we can't).
Can you change the load path on the fly reliably on windows?
Just to be sure I understand you, are you talking about the window's shell's %PATH% environment variable rather than Ruby's $LOAD_PATH load path? So we're not talking about $LOAD_PATH shift and unshift fun, right? Or maybe it's a combination of both?
If by changing load path on the fly in windows you mean %PATH%, I'm not aware of how do to this dynamically. I do know you can make progress with creating a "contained" PATH by using SETLOCAL in your .bat script files.
Also, are you aware of NTFS junctions ("windows symlinks")? http://technet.microsoft.com/en-us/sysinternals/bb896768.aspx Although they appear to be better supported in Vista, I haven't used them enough to know how robust of a solution they'd be. Would the rip gem need to have a custom DLL/exe for using rip? CRT compilation issues? etc?? And the usage recommendations in the KB article look interesting.
I don't know what Luis had in mind, but what I wanted to look into was the idea of having $RIPDIR/active reference the base path of the active environment in $RIPDIR and use $LOAD_PATH rewriting trickery so that the 'rip' executable (likely a batch script file in combination with a Ruby script) would get the right working environment when it ran.....'rip' (in C:\Ruby19\bin for example) would likely need some combination of SETLOCAL usage in combination with "ruby.exe -S" invocation. I hope to make some time to check into this to see if it's anything more than a red herring.
One suggestion, you may want to ping Luis, Roger Pack, or JRuby Charlie on this thread and see what magic they can help stir up :)
In case I don't get to this quickly enough, here's roughly what I'm thinking...maybe someone with some spare time can check into it (or rip it apart and find its flaws) if they're interested.....
This should really be first tested on a Win2K or WinXP box so as to catch any spaces-in-paths issues with having $RIPDIR in places like "C:\Documents and Settings\user"
1) Create a "testrip.bat" file in the primary Ruby bin dir, e.g. "C:\Ruby19\bin"
2) Create a fake $RIPDIR dir structure in "%USERPROFILE%.rip" that contains a couple fake environments each with a "bin" and "lib" dir. In each "bin" create a simple .bat "command file" that simply calls another .bat in it's corresponding "lib" dir that simply does a unique echo message.
3) Create a "%USERPROFILE%.rip\active" file that simply contains the name (really the relative path to a dir) of the currently active rip environment.
4) Edit the "C:\Ruby19\bin\testrip.bat" to do:
SETLOCAL
set RIPDIR="%USERPROFILE%.rip"set ARIPENV=[result of parsing "%USERPROFILE%.rip\active" using "FOR /F"]
rem initially create a really restricted PATH, relax as needed based on testing
set PATH=%RIPDIR%\%ARIPENV%\bin;C:\Ruby19\bin;%WINDIR%\system32;%WINDIR%
set RUBYLIB=%RIPDIR%\%ARIPENV%\librem put in some code to handle invocations of "testrip.bat" like
rem "testrip environment command"
rem in which is the name of the "command file" from step (2)@CALL and see if the PATH hackery works
5) Test/fix/curse as needed and if all looks good, replace the .bat files in each environment's "bin" and "lib" subdirs with Ruby scripts, update the "testrip.bat" file appropriately, and use "ruby -S " rather than the "@CALL "
6) If things are still holding together start figuring out how to integrate this with RubyGems as RubyGems does a little two step file autogenerating by creating a .bat and a corresponding Ruby script in C:\Ruby19\bin. Need to hijack/override this?
7) If things are STILL holding, start figuring out what needs to change in the rip source in order to rewrite "%USERPROFILE%.rip\active" in response to a "rip env use" command.
8) STILL holding??...test with JRuby on Win2K/WinXP.
9) STILL holding???...test trying to use both Ruby 1.8 and Ruby 1.9 interpreter on the same system.
10) STILL holding???? Start looking at how to do something similar on my xubuntu system
10) If none of this works, start looking at using dl, ffi to reach down to the Win32 API and investigate if NTFS junction points can safely and reliably emulate symlinking on Win2K+ systems. Ugh. Will this break other Ruby implementations such as JRuby, IronRuby, Rubinius????
Three issues I already see with this:
1) limited to single users
2) it assumes that the changing and use of rip environments always uses the "rip" command that runs to completion...no programmatic manipulation. For example, you probably have to do "rip env use myenv" and let it update "%USERPROFILE.rip\archive" and then run your other commands.
3) running a daemon and being able to correctly use different interpreters an issue???This sounds pretty great. I guess the question is: what are people on Windows going to use Rip for? Development? Deployment?
I think if we start by targeting those using Rip for development, it'll be easier to tack on deployment (and multi-user support) later on.
I agree; I plan to use Rip first for development. Play with it, see how it fits in with how I develop, and see what it starts to enable.
I think developers (Windows and non-Windows) will need to first get comfortable with it for development before they try other things. That's why I think it's so important to make Rip cross-platform early on. To me, cross-platform minimally means being able to install and run Rip on *nix and Windows XP or higher systems using MRI and JRuby runtimes supporting 1.8.6 and 1.9.x.
Ok, back to this issue....
1) Has any Windows developer yet provided feedback/prototype of this symlinking alternative? One of us really needs to whip up a prototype branch and git it to you to put into the main repo so others can dig into it.
2) What specific Windows systems do you have access to for testing out ideas, etc?
-
0 votes
0 comments Created 5 months ago by jonforumsUnable to install on WinXP with Ruby 1.9.1p129windowsxUsing 1.9.1p129 from http://rubyinstaller.org/downloads/ along with the MSys/MinGW-based DevKit on a WinXP Home SP3 system, I get the following.
At this early stage, I suspect that Windows usability may not be a high priority, but when I saw that the error dealt with trying to install the 'rip' executable to /usr/local/bin I thought this might be an easy one to knock down.
C:\Documents and Settings\Jon\My Documents>gem19 install rip
Building native extensions. This could take a while...
ERROR: Error installing rip:
ERROR: Failed to build gem native extension.c:/ruby1.9/bin/ruby.exe extconf.rb
rip: installing library files
rip: installing rip binary
rip: something failed, rolling back...
c:/ruby1.9/lib/ruby/1.9.1/fileutils.rb:1264:in `initialize': No such file or directory - /usr/local/
bin/rip (Errno::ENOENT)
from c:/ruby1.9/lib/ruby/1.9.1/fileutils.rb:1264:in `copy_stream' from c:/ruby1.9/lib/ruby/1.9.1/fileutils.rb:1264:in `copy_file' from c:/ruby1.9/lib/ruby/1.9.1/fileutils.rb:471:in `copy_file' from c:/ruby1.9/lib/ruby/1.9.1/fileutils.rb:392:in `block in cp' from c:/ruby1.9/lib/ruby/1.9.1/fileutils.rb:1394:in `block in fu_each_src_dest' from c:/ruby1.9/lib/ruby/1.9.1/fileutils.rb:1410:in `fu_each_src_dest0' from c:/ruby1.9/lib/ruby/1.9.1/fileutils.rb:1392:in `fu_each_src_dest' from c:/ruby1.9/lib/ruby/1.9.1/fileutils.rb:391:in `cp' from c:/ruby1.9/lib/ruby/gems/1.9.1/gems/rip-0.0.1/lib/rip/setup.rb:73:in `block in install_binary' from c:/ruby1.9/lib/ruby/gems/1.9.1/gems/rip-0.0.1/lib/rip/setup.rb:131:in `call' from c:/ruby1.9/lib/ruby/gems/1.9.1/gems/rip-0.0.1/lib/rip/setup.rb:131:in `transaction' from c:/ruby1.9/lib/ruby/gems/1.9.1/gems/rip-0.0.1/lib/rip/setup.rb:70:in `install_binary' from c:/ruby1.9/lib/ruby/gems/1.9.1/gems/rip-0.0.1/lib/rip/setup.rb:36:in `install' from c:/ruby1.9/lib/ruby/gems/1.9.1/gems/rip-0.0.1/setup.rb:26:in `<top (required)>' from extconf.rb:11:in `require' from extconf.rb:11:in `<main>'Gem files will remain installed in c:/ruby1.9/lib/ruby/gems/1.9.1/gems/rip-0.0.1 for inspection.
Results logged to c:/ruby1.9/lib/ruby/gems/1.9.1/gems/rip-0.0.1/ext/gem_make.outComments
-
I've started to convert the doc from the gh-pages branch into a man page for fun's sake and to learn about how man pages are made. sr@e475ed9
Comments
-
A half or maybe all the way drunken implementation of tab completion: http://github.com/defunkt/rip/commit/c42b66a8c79e6065d917e4e992063c2737973c2c
You need to add
complete -o default -o nospace -C "$HOME/git/forks/rip/tools/completions" ripto your bash profile somewhere to make it work.If only I knew anything about tree data structures.. I'm sort of looking for help here. Also, implementing it in Ruby makes it hella-slow.
Comments
I meant to look into comletion for zsh too :) but first, I'd like to change the rip commands as they're not as good as they could be, IMO. I am thinking of something less-chatty, probably more git-y. I'll probably start with a quick wrapper on top of
ripto illustrate my point. BTW, you might want to have a look at http://github.com/drnic/tabtab -
1 vote
Integration test for git package and support for installing a git ref
0 comments Created 5 months ago by srhttp://github.com/sr/rip/tree/git
I initially started to write acceptance test in Ruby, but then I figured that wasn't integration-y enough so I wrote some more unusual tests, inspired by git's test suite. In my opinion, that kind of test are easier to write, much closer to reality and in fact, better. Also, it was fun to write them :)
While I was there, I also implemented support for
rip install git://example.org/repo refwhere ref can be a sha1, a tag, a branch of a full git ref (refs/heads/foo). (I am not happy with the code, though)BTW, for better output, run the test like this:
./t/test-git | ./t/knock/kn-sum
If you like those test, I'll add a Makefile or something (with xargs -P to speed up the test?) to ease the process of running the tests.Comments
-
specs/tests are currently failing on HEAD:
Comments
smtlaissezfaire
Wed Jul 29 01:47:55 -0700 2009
| link
speaking of which - is there a build server for rip around?
-
If I am installing the rip gem, it should not attempt to set up a ripenv.
Specifically, if I am attempting to install rip using something like Chef, I should not have to create a user-specific shell configuration file for the user I am running Chef as just so that I can install the rip gem.
While I understand that rip creates per-user virtual environments, that behavior is not typical of a gem and rather unexpected.
Comments
Rip is not a RubyGem. Rip uses RubyGems to bootstrap its installation.
gem uninstall ripwill not uninstall Rip. You must userip uninstall rip.That said, we could add a
--no-ripenvoption to the installation so that Rip only installs its own files. Do you think that would work? -
rip install git://github.com/datamapper/dm-more.git/dm-clirip install git://github.com/rails/rails.git/activerecordComments
-
Not a huge deal, but uninstall does not clean up any compiled bundles.
Rip looks through the package cache to figure out what files belong to the package. Compiled code is built in the ripenv not in the cache. Therefore never gets cleaned up.
Possible solutions:
1) Start tracking package files w/o needing the package cache. This could make uninstalling a bit more robust overall. However it seems like alot of work.
2) Build native packages inside the cache and then copy the files over. This seems like the simplest solution but I'm not sure if any compiled code depends on being in the directory it was built in.Comments
-
I should have some proxy support, through env variable is better than nothing
Comments
-
Hello,
Whether I install RIP with or without gem on debian, I get the following error :
http://gist.github.com/176993Comments
-
0 votes
Rehash to find new binaries after environment change
0 comments Created 3 months ago by lazyatomWhen flipping between environments, the paths to binaries can change (one environment might have rake installed; another might not, and so the shell should fall back to the system rake). Is it worth calling
rehashafter an environment is activated?We could accomplish this to some extent with hooks, but they would need to be manually installed for each environment, and easy to forget.
Comments
-
In ruby 1.9, the instance_methods used by Rip::Env now returns an array of symbols. In order to make the rip env command work I converted the Rip::Env:commands to work with symbols.
index 42e792d..3e0dc5c 100644 --- a/lib/rip/commands/core.rb +++ b/lib/rip/commands/core.rb @@ -27,7 +27,7 @@ module Rip x 'Commands for managing your ripenvs.' x 'Type rip env to see valid options.' def env(options = {}, command = nil, *args) - if command && Rip::Env.commands.include?(command) + if command && Rip::Env.commands.include?(command.to_sym) args.push(options) ui.puts 'ripenv: ' + Rip::Env.call(command, *args).to_s else diff --git a/lib/rip/env.rb b/lib/rip/env.rb index 8dabc40..e7e2122 100644 --- a/lib/rip/env.rb +++ b/lib/rip/env.rb @@ -5,7 +5,7 @@ module Rip PRIVATE_ENV = /^(rip-|active)/i def commands - instance_methods - %w( call active_dir commands ui validate_ripenv ) + instance_methods - [:call, :active_dir, :commands, :ui, :validate_ripenv] end x 'Create the SOURCE environment.'Comments
This patch gets Rip closer to working under 1.9 for me. I don't quite understand the use of
Enumerable#any?at lib/rip/sh/gem.rb, line 7 but it's pretty clearly breaking under ruby-1.9.1-p243:(master) root@devbox:~# rip install sinatra undefined method `any?' for "/opt/ruby-1.9.1-p243/bin/gem":String rip: install failed -> undefined method `any?' for "/opt/ruby-1.9.1-p243/bin/gem":String (master) root@devbox:~# -
0 votes
PATH setup inconsistent between fish and bash/zsh
0 comments Created about 1 month ago by chesThe fish template prepends active ripenv bin to
PATH, while for bash/zsh it is appended.Personally I would want it prepended, with use alongside rubygems, etc. in mind: I will keep my base ripenv trim and tidy for everyday use, falling back to rubygems-installed executables at system-level. When I use another ripenv, I most certainly want priority given to its libs and executables.
It's easy enough to change the generated shell config, but that goes against the decision to install it by default :-) I'm curious if there is reasoning for appending or if it was an oversight -- in any case, it should be consistent between shells.
Comments
You can pass
--bindir--libdirand--ripdirto the gem installation process to choose what paths you'd like it installed to.Can you give it a shot and let me know if it works?
After running
gem install rip -- --build-flags --bindir=$PREFIX/bin --libdir=$PREFIX/lib/ruby --ripdir=$PREFIX/lib/rip:(PREFIX is $HOME/.local)