ruby_select experimental implementation
C. Florian Ebeling
florian.ebeling at gmail.com
Sun May 10 11:31:10 PDT 2009
On Sun, May 10, 2009 at 5:55 PM, Rainer Müller <raimue at macports.org> wrote:
> C. Florian Ebeling wrote:
>> One other thing I noticed is that ruby_select does not
>> declare any dependency on any ruby, which surprised me
>> a bit. But python does not require any python either.
>> There is probably some reasoning behind this. I would
>> like to learn more about the this.
>
> I would find it a bit strange if *_select required a specific version.
> Instead, the ruby and python versions should require *_select.
Ok, that way around it sounds reasonable. Although, you could immediately
select a default, if we were pulling one version via the select port, and offer
flexibility using variants.
> See <http://trac.macports.org/ticket/19126>
>
>> These two behaviours together, though, leave users in the
>> situation where they install ruby_select, then issue
>>
>> sudo ruby_select ruby186
>>
>> which does not complain, but there won't be a usable ruby
>> afterwards, only a couple of symlinks pointing into the nowhere.
>
> As I said before, the select files should be part of the corresponding
> ports and not of *_select. This way it is only possible to select
> versions which are installed and active.
Ok, got it. Cheers :)
As it seems it is even possible to have a variable number of executables
or files in the various selectables, is that true? That might help
with rake and gem, which are only part of the 1.9 release.
Any idea what select does when it encouters a real file being in the place
where it intends to put a symlink?
Btw: The 'port select' in trunk, which is mentioned in the ticket, does
that indeed obsolete all these efforts?
Florian
--
Florian Ebeling
Twitter: febeling
florian.ebeling at gmail.com
More information about the macports-dev
mailing list