ruby_select plan, rubygem: dependency operator

[Bryan Blackburn]

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.

Bryan


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