ruby_select plan, rubygem: dependency operator

[Bryan Blackburn]

On Mon, Apr 13, 2009 at 02:47:11PM +0200, C. Florian Ebeling said:
> In the last couple days Brett Eisenberg, Wataru Kimura and I have been
> discussing
> a few changes to the Ruby ports on private mail, and I wanted to put
> this publicly onto
> the list for dicussion. Nothing earthshaking, but sure worth discussion.
> 
> It started with Brett's suggestion to have ruby 1.9 as default ruby,
> without suffix.
> That is possible already by setting the nosuffix variant. It would
> been more convenient
> and more consistent across MacPorts to use the *_select approach, which python
> and gcc have adopted. This is the solution we have agreed on now among us.
> 
> So the course of action will be:
> 1 rename ruby port to ruby18
> 2 create ruby_select port
> 
> I added the suggestion to maybe have another third step:
> 3 create port ruby again which is empty mostly, but pulls select_ruby
> and symlinks
> to default version (which ever that is then) This one is not agreed on yet
> and still to be discussed.

You'll definitely need some sort of upgrade path for anyone with ruby
currently installed; otherwise, if you try to install something which
depends on the new ruby18, that will then fail during activation since it
will conflict with files from ruby.

Also note that upgrading depedencies when installing a new port doesn't
happen automatically, so for those who may not upgrade regularly, this will
still be an issue.

Does this mean there will start to be rb19- ports as well, to have them
depend on ruby19?  Since ruby modules install into version-specific
locations (using rb-bdb's ${prefix}/lib/ruby/vendor_ruby/1.8 path as an
example), it seems like some form of consistency will be needed.  Otherwise
someone installs rb-bdb with ruby18 selected, then later switches to ruby19
and now rb-bdb doesn't work, right?

Bryan


> 
> Other ideas came up as well. It is not really very convincing to have rubygems
> installed through mp, marked as installed, accidentially uninstalled
> directly using
> the gem command and break downstream apps that rely on these dependencies.
> Kimura had the idea to introduce a new dependency type, rubygem: maybe,
> which would largely work like path: or lib: dependencies. I like that
> approach and will
> write a ticket for this.
> 
> An open question is wether to include jruby and other implementations as well.
> But that can come later as well.
> 
> What do you think of the plan? Any commentary, maybe educated by python
> experiences?
> 
> Florian
> 
> 
> -- 
> Florian Ebeling
> Twitter: febeling
> florian.ebeling at gmail.com