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