ruby_select plan, rubygem: dependency operator

C. Florian Ebeling febeling at macports.org
Wed Apr 15 02:40:49 PDT 2009


On Wed, Apr 15, 2009 at 10:02 AM, Ryan Schmidt <ryandesign at macports.org> wrote:
>
> On Apr 14, 2009, at 15:30, C. Florian Ebeling wrote:
>
>> 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.
>
> I don't quite understand how this suggestion would work, and on principle I
> think I'm not in favor of adding a new dependency type which is specific to
> a particular type of software. All existing dependency types are generic and
> applicable to all types of software, which is IMHO as it should be. If you
> want to depend on a gem, there should be a port for that gem, and you
> declare a dependency on the port as you would for any other type of
> software. There could, though, be shortcuts that would make such portfiles
> smaller. I think that would fall under the umbrella of a portgroup, like the
> perl5 portgroup for simplifying Perl CPAN modules or the upcoming pecl
> portgroup for PHP PECL modules.

That's what we have right now with ruby group and ruby.setup call.
The problem is that the gem can be uninstalled through gem, leaving
an inconsistent install state behind in the mp registry.

I think that can come up with other dynamic languages as well, when
they have similar special package managers.





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


More information about the macports-dev mailing list