ruby_select plan, rubygem: dependency operator

[C. Florian Ebeling]

On Mon, Apr 13, 2009 at 11:25 PM, Bryan Blackburn <blb at macports.org> wrote:
> On Mon, Apr 13, 2009 at 10:21:08PM +0200, C. Florian Ebeling said:
>> >> 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.
>>
>> Yes, that's true. Didn't think of it. Are you aware of a
>> similar migration that was handled well and that can
>> be use as an example to follow?
>
> Unfortunately no, I think part of the problem is this need hasn't come up
> enough for there to be good support to handle it in base.  If there were we
> could probably also more easily fix the 'not a directory' issue with
> python25 without causing pain.
>
> Unless there's better support in base for such things, the best option may
> be to try and document it with the right ports (via ui_msg) and mailing
> lists/FAQ/etc that certain things are needed for the newer stuff to work
> right...

Hm, then it is really the question if this is worth the users' hassle, only
for the sake of an somewhat better naming. Python also has an largely
obsolete python (without version suffix) port, hasn't it?

>> > 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?
>>
>> Yes, that's the behaviour of the ruby group code
>> already. It uses rb19 as prefix for ruby19 ports.
>
> Ah, okay, I didn't see any rb19- ports but didn't look at the group code.
> Is there a possibility that they could eventually be merged once #126 is
> done, similar to how we'd like the python modules to work, as mentioned in
> #16723?

The group code is already the same for ruby (1.8) and ruby19. There are
no rb19 ports yet because most ruby developers prefer rubygems over
ports using the 'gem' package manager. This tool now comes with
the (1.9) ruby release. So this approach mostly obsoletes older install.rb
and setup.rb methods. And gems as ports have issues.

We have ports that are only a skin over rubygem installs, but that approach
is not ideal, because you can e.g. install the port and uninstall the gem, just
using the gem tool. And then it is registered as installed, where it
really isn't
present as a library. I and others therefore think that ports just brokering
gem installs should be avoided if possible.

The obvious problem with no ruby lib ports is, once you want to add a port that
depends on a gem library, you cannot declare it.

That's the reason for the suggestion to add a new dependency type "gem" or
"rubygem", which behaves much like "path" or "lib" dependencies. Not controlling
installation, but checking.

Florian

-- 
Florian Ebeling
Twitter: febeling
florian.ebeling at gmail.com