ruby_select plan, rubygem: dependency operator

[C. Florian Ebeling]

In the last couple days Brett Eisenberg, Wataru Kimura and I have been
discussing
a few changes to the Ruby ports on private mail, and I wanted to put
this publicly onto
the list for dicussion. Nothing earthshaking, but sure worth discussion.

It started with Brett's suggestion to have ruby 1.9 as default ruby,
without suffix.
That is possible already by setting the nosuffix variant. It would
been more convenient
and more consistent across MacPorts to use the *_select approach, which python
and gcc have adopted. This is the solution we have agreed on now among us.

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.

Other ideas came up as well. It is not really very convincing to have rubygems
installed through mp, marked as installed, accidentially uninstalled
directly using
the gem command and break downstream apps that rely on these dependencies.
Kimura had the idea to introduce a new dependency type, rubygem: maybe,
which would largely work like path: or lib: dependencies. I like that
approach and will
write a ticket for this.

An open question is wether to include jruby and other implementations as well.
But that can come later as well.

What do you think of the plan? Any commentary, maybe educated by python
experiences?

Florian






--
Florian Ebeling
Twitter: febeling
florian.ebeling@...
_______________________________________________
macports-dev mailing list
macports-dev@...
http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev

[Bryan Blackburn-4]

On Mon, Apr 13, 2009 at 02:47:11PM +0200, C. Florian Ebeling said:

> In the last couple days Brett Eisenberg, Wataru Kimura and I have been
> discussing
> a few changes to the Ruby ports on private mail, and I wanted to put
> this publicly onto
> the list for dicussion. Nothing earthshaking, but sure worth discussion.
>
> It started with Brett's suggestion to have ruby 1.9 as default ruby,
> without suffix.
> That is possible already by setting the nosuffix variant. It would
> been more convenient
> and more consistent across MacPorts to use the *_select approach, which python
> and gcc have adopted. This is the solution we have agreed on now among us.
>
> 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.

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?

Bryan

>
> Other ideas came up as well. It is not really very convincing to have rubygems
> installed through mp, marked as installed, accidentially uninstalled
> directly using
> the gem command and break downstream apps that rely on these dependencies.
> Kimura had the idea to introduce a new dependency type, rubygem: maybe,
> which would largely work like path: or lib: dependencies. I like that
> approach and will
> write a ticket for this.
>
> An open question is wether to include jruby and other implementations as well.
> But that can come later as well.
>
> What do you think of the plan? Any commentary, maybe educated by python
> experiences?
>
> Florian
>
>
> --
> Florian Ebeling
> Twitter: febeling
> florian.ebeling@...

_______________________________________________
macports-dev mailing list
macports-dev@...
http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev

[febeling]

>> 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?

>
> 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.

Florian

--
Florian Ebeling
Twitter: febeling
florian.ebeling@...
_______________________________________________
macports-dev mailing list
macports-dev@...
http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev

[Bryan Blackburn-4]

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...

>
> >
> > 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?

Bryan


>
> Florian
>
> --
> Florian Ebeling
> Twitter: febeling
> florian.ebeling@...
_______________________________________________
macports-dev mailing list
macports-dev@...
http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev

[C. Florian Ebeling]

On Mon, Apr 13, 2009 at 11:25 PM, Bryan Blackburn <blb@...> 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@...
_______________________________________________
macports-dev mailing list
macports-dev@...
http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev

[Bryan Blackburn-4]

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@...> 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@...
_______________________________________________
macports-dev mailing list
macports-dev@...
http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev

[Ryan Schmidt-24]

On Apr 14, 2009, at 18:41, Bryan Blackburn wrote:

> 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.

In lieu of this, a tool to mostly-automatically convert from those  
package managers to a MacPorts port is useful, c.f. cpan2port for  
converting CPAN perl modules to Portfiles.


_______________________________________________
macports-dev mailing list
macports-dev@...
http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev

[Ryan Schmidt-24]

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.

http://trac.macports.org/ticket/18839

_______________________________________________
macports-dev mailing list
macports-dev@...
http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev

[febeling]

>> 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.
>
> In lieu of this, a tool to mostly-automatically convert from those package
> managers to a MacPorts port is useful, c.f. cpan2port for converting CPAN
> perl modules to Portfiles.

A ruby port also consists of only 3 or 4 lines of effective code, if you use
the ruby.setup call from the ruby group file. What worries me more is
the brittleness when you just can pull away dependencies using the
special package manager, gem in the ruby case.




>
>
> _______________________________________________
> macports-dev mailing list
> macports-dev@...
> http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev
>



--
Florian Ebeling
Twitter: febeling
florian.ebeling@...
_______________________________________________
macports-dev mailing list
macports-dev@...
http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev

[febeling]

On Wed, Apr 15, 2009 at 1:41 AM, Bryan Blackburn <blb@...> 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@...> 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@...
_______________________________________________
macports-dev mailing list
macports-dev@...
http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev

[Ryan Schmidt-24]

On Apr 15, 2009, at 03:03, C. Florian Ebeling wrote:

> A ruby port also consists of only 3 or 4 lines of effective code,  
> if you use
> the ruby.setup call from the ruby group file. What worries me more is
> the brittleness when you just can pull away dependencies using the
> special package manager, gem in the ruby case.

Yes, it would be good to fix it so that users cannot cause that problem.

_______________________________________________
macports-dev mailing list
macports-dev@...
http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev

[febeling]

On Wed, Apr 15, 2009 at 11:19 AM, Ryan Schmidt <ryandesign@...> wrote:

>
> On Apr 15, 2009, at 03:03, C. Florian Ebeling wrote:
>
>> A ruby port also consists of only 3 or 4 lines of effective code, if you
>> use
>> the ruby.setup call from the ruby group file. What worries me more is
>> the brittleness when you just can pull away dependencies using the
>> special package manager, gem in the ruby case.
>
> Yes, it would be good to fix it so that users cannot cause that problem.

I don't see what the correct behaviour is, when having a port that wraps
over a gem, for instance. When the gem is loadable as ruby library, then
it is visible to the gem manager, and can be removed as well. Even if
there was a way to make a gem visible but not manipulatable, that would
be very strange behaviour from a ruby/gem perspective.

So I suggest not trying to stay in control here, but rather act like for
other dependencies for which we don't exert control (path, lib).

Or do you have an idea how to really fix this problem?





--
Florian Ebeling
Twitter: febeling
florian.ebeling@...
_______________________________________________
macports-dev mailing list
macports-dev@...
http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev

[C. Florian Ebeling]

On Wed, Apr 15, 2009 at 10:02 AM, Ryan Schmidt <ryandesign@...> 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@...
_______________________________________________
macports-dev mailing list
macports-dev@...
http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev

[Ryan Schmidt-24]

On Apr 15, 2009, at 04:35, C. Florian Ebeling wrote:

> On Wed, Apr 15, 2009 at 11:19 AM, Ryan Schmidt wrote:
>
>> On Apr 15, 2009, at 03:03, C. Florian Ebeling wrote:
>>
>>> A ruby port also consists of only 3 or 4 lines of effective code,  
>>> if you
>>> use the ruby.setup call from the ruby group file. What worries me
>>> more is the brittleness when you just can pull away dependencies
>>> using the special package manager, gem in the ruby case.
>>
>> Yes, it would be good to fix it so that users cannot cause that  
>> problem.
>
> I don't see what the correct behaviour is, when having a port that  
> wraps
> over a gem, for instance. When the gem is loadable as ruby library,  
> then
> it is visible to the gem manager, and can be removed as well. Even if
> there was a way to make a gem visible but not manipulatable, that  
> would
> be very strange behaviour from a ruby/gem perspective.
>
> So I suggest not trying to stay in control here, but rather act  
> like for
> other dependencies for which we don't exert control (path, lib).
>
> Or do you have an idea how to really fix this problem?

How does the perl5 portgroup handle it? Is it using CPAN to install  
the modules, and can they then be uninstalled or upgraded by the user  
by using the cpan command?

For the pecl portgroup I'm working on, which will be based on the  
existing php5-* module ports, we do not use the pear command to  
install, so the user will hopefully not be able to use pear to  
upgrade or uninstall either.

Maybe it is simply a user error to use gem or cpan to manipulate  
those packages, and users just need to be educated to use MacPorts  
for all software installations.


_______________________________________________
macports-dev mailing list
macports-dev@...
http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev

[febeling]

On Wed, Apr 15, 2009 at 12:16 PM, Ryan Schmidt <ryandesign@...> wrote:

>
> On Apr 15, 2009, at 04:35, C. Florian Ebeling wrote:
>
>> On Wed, Apr 15, 2009 at 11:19 AM, Ryan Schmidt wrote:
>>
>>> On Apr 15, 2009, at 03:03, C. Florian Ebeling wrote:
>>>
>>>> A ruby port also consists of only 3 or 4 lines of effective code, if you
>>>> use the ruby.setup call from the ruby group file. What worries me
>>>> more is the brittleness when you just can pull away dependencies
>>>> using the special package manager, gem in the ruby case.
>>>
>>> Yes, it would be good to fix it so that users cannot cause that problem.
>>
>> I don't see what the correct behaviour is, when having a port that wraps
>> over a gem, for instance. When the gem is loadable as ruby library, then
>> it is visible to the gem manager, and can be removed as well. Even if
>> there was a way to make a gem visible but not manipulatable, that would
>> be very strange behaviour from a ruby/gem perspective.
>>
>> So I suggest not trying to stay in control here, but rather act like for
>> other dependencies for which we don't exert control (path, lib).
>>
>> Or do you have an idea how to really fix this problem?
>
> How does the perl5 portgroup handle it? Is it using CPAN to install the
> modules, and can they then be uninstalled or upgraded by the user by using
> the cpan command?
>
> For the pecl portgroup I'm working on, which will be based on the existing
> php5-* module ports, we do not use the pear command to install, so the user
> will hopefully not be able to use pear to upgrade or uninstall either.

That is an approach that is certainly not acceptable for the
ruby community. There is really virbrant exchange and reuse
of gems over platforms like GutHub these days, and gem
comes as part of the standard ruby release. All these ruby
people would just walk away from MacPorts if where to try
and shut down use of gem for them.

I don't know if there is a way to make gems install in a
different location from port, and still have it visible from
ruby loading point of view. But I am pretty sure that view
is identical with the one gem sees in general, by virtue
of being a plain ruby script. Because of we made ruby
scripts require to add to the load path to see gems from
mp that would defy the effort.

>
> Maybe it is simply a user error to use gem or cpan to manipulate those
> packages, and users just need to be educated to use MacPorts for all
> software installations.

I agree, at the moment it is. But I think we could do a better job there.
Maybe these rubygems dependencies could even be installed without
a portfile and right through the special installer. Or that is too ambitious
and port should just fail and explain the missing dependency and show
the command to bring them into place. I don't know.

But the current situation is not really ideal. I understand your reluctance
to introduce very high-level dependency operators/types, because normally
MacPorts shouldn't have such a notion as "rubygem." But what are
better alternatives. As said, I find the "This is a user error" view not
too compelling (still it would involve the least work - we have it ;)





--
Florian Ebeling
Twitter: febeling
florian.ebeling@...
_______________________________________________
macports-dev mailing list
macports-dev@...
http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev

[Ryan Schmidt-24]

On Apr 15, 2009, at 07:07, C. Florian Ebeling wrote:

> On Wed, Apr 15, 2009 at 12:16 PM, Ryan Schmidt wrote:
>
>> On Apr 15, 2009, at 04:35, C. Florian Ebeling wrote:
>>
>>> On Wed, Apr 15, 2009 at 11:19 AM, Ryan Schmidt wrote:
>>>
>>>> On Apr 15, 2009, at 03:03, C. Florian Ebeling wrote:
>>>>
>>>>> A ruby port also consists of only 3 or 4 lines of effective  
>>>>> code, if you
>>>>> use the ruby.setup call from the ruby group file. What worries me
>>>>> more is the brittleness when you just can pull away dependencies
>>>>> using the special package manager, gem in the ruby case.
>>>>
>>>> Yes, it would be good to fix it so that users cannot cause that  
>>>> problem.
>>>
>>> I don't see what the correct behaviour is, when having a port  
>>> that wraps
>>> over a gem, for instance. When the gem is loadable as ruby  
>>> library, then
>>> it is visible to the gem manager, and can be removed as well.  
>>> Even if
>>> there was a way to make a gem visible but not manipulatable, that  
>>> would
>>> be very strange behaviour from a ruby/gem perspective.
>>>
>>> So I suggest not trying to stay in control here, but rather act  
>>> like for
>>> other dependencies for which we don't exert control (path, lib).
>>>
>>> Or do you have an idea how to really fix this problem?
>>
>> How does the perl5 portgroup handle it? Is it using CPAN to  
>> install the
>> modules, and can they then be uninstalled or upgraded by the user  
>> by using
>> the cpan command?
>>
>> For the pecl portgroup I'm working on, which will be based on the  
>> existing
>> php5-* module ports, we do not use the pear command to install, so  
>> the user
>> will hopefully not be able to use pear to upgrade or uninstall  
>> either.
>
> That is an approach that is certainly not acceptable for the
> ruby community. There is really virbrant exchange and reuse
> of gems over platforms like GutHub these days, and gem
> comes as part of the standard ruby release. All these ruby
> people would just walk away from MacPorts if where to try
> and shut down use of gem for them.
>
> I don't know if there is a way to make gems install in a
> different location from port, and still have it visible from
> ruby loading point of view. But I am pretty sure that view
> is identical with the one gem sees in general, by virtue
> of being a plain ruby script. Because of we made ruby
> scripts require to add to the load path to see gems from
> mp that would defy the effort.
>
>>
>> Maybe it is simply a user error to use gem or cpan to manipulate  
>> those
>> packages, and users just need to be educated to use MacPorts for all
>> software installations.
>
> I agree, at the moment it is. But I think we could do a better job  
> there.
> Maybe these rubygems dependencies could even be installed without
> a portfile and right through the special installer. Or that is too  
> ambitious
> and port should just fail and explain the missing dependency and show
> the command to bring them into place. I don't know.
>
> But the current situation is not really ideal. I understand your  
> reluctance
> to introduce very high-level dependency operators/types, because  
> normally
> MacPorts shouldn't have such a notion as "rubygem." But what are
> better alternatives. As said, I find the "This is a user error"  
> view not
> too compelling (still it would involve the least work - we have it ;)

Find a way to install the gem in a MacPorts port that does not cause  
the gem to show up when a user runs "gem". Build this into the ruby  
portgroup. Maybe we need to have a patched version of gem that we  
use. Maybe we need to not use gem at all to install.

_______________________________________________
macports-dev mailing list
macports-dev@...
http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev

[Rainer Müller-4]

Bryan Blackburn wrote:

> 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.

Such cpan: or rubygem: dependencies would cause some problems. If there
is no port for a language module, I would have to use cpan or gem to
install it. This is probably acceptable for developers, but quite
complicated for users.

And in the ongoing effort to provide binaries, it would probably cause
problems to make binary archives of these dependencies as no Portfiles
exist.

So if we are going to do something like this, we do not only need it for
dependencies, but also a new way to refer to such a "port" from the
command line.

How would we specify additional build options or customizations to fit
better into MacPorts? Probably only using a port. So if this is going to
be implemented, it should still always check if a port of that name
exists and prefer that.

Rainer
_______________________________________________
macports-dev mailing list
macports-dev@...
http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev