ruby_select plan, rubygem: dependency operator

[C. Florian Ebeling]

On Wed, Apr 15, 2009 at 1:41 AM, Bryan Blackburn <blb at macports.org> wrote:
> On Tue, Apr 14, 2009 at 10:30:11PM +0200, C. Florian Ebeling said:
>> On Mon, Apr 13, 2009 at 11:25 PM, Bryan Blackburn <blb at macports.org> wrote:
> [...]
>> >
>> > 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?
>
> The py-* modules are all python 2.4-based modules, but since 2.5 is the
> currently-popular version and 2.6 starting to kick in, like you say it
> isn't worth the effort to rename to py24-*.
>
> [...]
>> >
>> > 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.
>
> What would be nice is some automatic wrapper for all the various extensions
> to languages (ruby, perl, python, etc) where you just say "I need xyz from
> CPAN/gem" and port can handle it, and hence use it for dependencies.  Of course,
> base has no support for such hence the need to wrap such things in full-blown
> ports, otherwise how do we know what is installed and and what version?  It
> would still run the install through the proper tool, but also keep track of
> what is installed so it can be managed (and easily upgraded, activated,
> etc), but wouldn't need to be a complete port.  Instead it could be some
> form of listing in a table someplace, for any extensions which are easily
> installed.

That was the idea, basically. :)




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