Re: Ruby on Rails support in Intrepid - call for reviewers and cheerleaders
Thanks for your work Neil! The ruby community is very much a bleeding edge group of developers, and so waiting 6 months between releases is really not useful. When I do my rails development on hardy, I install ruby, mysql, and ruby gems from apt, and from there use straight gems. -- Darren On Wed, Aug 20, 2008 at 7:31 AM, Stephan Hermann <[EMAIL PROTECTED]> wrote: > On Wed, Aug 20, 2008 at 02:07:46PM +0100, Neil Wilson wrote: >> Scott, >> >> I'm trying to avoid the wheres and wherefores of what gem is about. >> Suffice to say that Rails depends upon effective gem support, such >> that the configuration of Rails can specify gem dependencies directly. >> >> So if Ubuntu wants Rails, it has to have Gem that works. Therefore I >> saw my task as trying to get gem to work as a user would expect it to >> work without gem destroying the operating system, leaving cruft lying >> around the filesystem in the wrong place and try and prevent it >> running into itself too much >> >> It's an exercise in containment. > > What about teaching ROR to use an overlay, especially for the webapp you > code for? > > I mean, the problem with gem is known...it's nasty... > afaik gem can do something like a destdir install somehow (when I'm not > mistaken and my mind is working in normal parameters, and my knowledge > from old ROR times is still valid). > If you have such a structure: > > /var/www/ROR_App1/<... std ror dirs ...> > /var/www/ROR_App1/gems/ ... > > this gems dir will be used as overlay, so somehow it needs to be > possible to LD_PRELOAD/LD_LIBRARY_PATH this directory (via config in > apache2/lighty/whereever) > >> >>What are you referring to exactly ? Which use case do you have in mind ? >> > >> >It's my understanding that gems produces one complete package (gem) with >> >all Ruby libs needed to run the application and that there is no internal >> >notion of versioning. >> >> Think of gem as a source package that generates binary packages on the >> fly. It has notions of build dependencies with other gems (including >> versioning) and run dependencies. >> >> One thing it can do is manage several versions of the same gem on the >> machine at the same time. >> >> For example the Rails gem depends upon the rake, activesupport, >> activerecord, actionpack, actionmailer and actionresource gems. You >> can install multiple different versions (usually one of each minor >> revision - 1.2.6, 2.0.2 and 2.1.0) and gem will ensure that the >> correct versions of the dependent gems are brought in at run time. > > As long as gems are only delivering their own binaries... > But gems are much more, you can include complete (one or more) upstream > packages (I had this at one ocasion, there was this imagemagick gem and > this module was only working with a special imagemagick version, so it > shipped it together with the other cruft, but instead of installing it > somewhere where this imagemagick lib didn't hurt, it was just a smartass > and installed it in /usr/lib, overwriting the distro imagemagick). > > This gem package didn't respect: DESTDIR, neither it respected the > ./configure --prefix=<...> commands...so it destroyed other apps...but > this wasn't documented anywhere, btw. > > so, having an overlay dir, where those gems can be installed without > disturbing the other software, fine...but not as it is now, and not > installing their stuff into /usr/local/lib or into /opt/foo > > Regards, > \sh > > -- > Stephan '\sh' Hermann | OSS Developer & Systemadministrator > JID: [EMAIL PROTECTED]| http://www.sourcecode.de/ > GPG ID: 0xC098EFA8 | http://leonov.tv/ > 3D8B 5138 0852 DA7A B83F DCCB C189 E733 C098 EFA8 > > -- > Ubuntu-devel-discuss mailing list > [EMAIL PROTECTED] > Modify settings or unsubscribe at: > https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss > -- Ubuntu-motu mailing list Ubuntu-motu@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu
Re: Ruby on Rails support in Intrepid - call for reviewers and cheerleaders
Good Morning David, Scott, On Thu, Aug 21, 2008 at 02:45:59PM -0400, Scott Kitterman wrote: > On Thu, 21 Aug 2008 12:42:58 -0500 David Portwood <[EMAIL PROTECTED]> wrote: > [...] > >> As long as gems are only delivering their own binaries... > >> But gems are much more, you can include complete (one or more) upstream > >> packages (I had this at one ocasion, there was this imagemagick gem and > >> this module was only working with a special imagemagick version, so it > >> shipped it together with the other cruft, but instead of installing it > >> somewhere where this imagemagick lib didn't hurt, it was just a smartass > >> and installed it in /usr/lib, overwriting the distro imagemagick). > >This is a good example of that, and it happens on more than just debian > >systems. I do however feel that Neils proposed change(s) to the gems > >package has the best intrest in mind without major changes to gem and > >apt. This is a step forward, no? > > I think that if gem was installing dependencies in a location that would > not interfere (e.g. be used instead of) installed system libraries, but > that the installed Gem could use the I could say yes to this. Which is the case, when gem would use overlay dirs and those would LD_PRELOADED/LD_LIBRARY_PATHed properly but this is something the ruby devs should take care of. In the meantime, the whole GEM stuff is broken by design, and I don't understand people who are fighting with this. As said before, I think the best way to handle this: Never ever use any other package management system, but from the used distro. Regards, -- Stephan '\sh' Hermann | OSS Developer & Systemadministrator JID: [EMAIL PROTECTED] | http://www.sourcecode.de/ GPG ID: 0xC098EFA8 | http://leonov.tv/ 3D8B 5138 0852 DA7A B83F DCCB C189 E733 C098 EFA8 -- Ubuntu-motu mailing list Ubuntu-motu@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu
Re: Ruby on Rails support in Intrepid - call for reviewers and cheerleaders
On Thu, 21 Aug 2008 12:42:58 -0500 David Portwood <[EMAIL PROTECTED]> wrote: >On Wed, 2008-08-20 at 15:31 +0200, Stephan Hermann wrote: >> On Wed, Aug 20, 2008 at 02:07:46PM +0100, Neil Wilson wrote: >> > Scott, >> > >> > I'm trying to avoid the wheres and wherefores of what gem is about. >> > Suffice to say that Rails depends upon effective gem support, such >> > that the configuration of Rails can specify gem dependencies directly. >> > >> > So if Ubuntu wants Rails, it has to have Gem that works. Therefore I >> > saw my task as trying to get gem to work as a user would expect it to >> > work without gem destroying the operating system, leaving cruft lying >> > around the filesystem in the wrong place and try and prevent it >> > running into itself too much >> > >> > It's an exercise in containment. >> >> What about teaching ROR to use an overlay, especially for the webapp you >> code for? >> >> I mean, the problem with gem is known...it's nasty... >> afaik gem can do something like a destdir install somehow (when I'm not >> mistaken and my mind is working in normal parameters, and my knowledge >> from old ROR times is still valid). >> If you have such a structure: >> >> /var/www/ROR_App1/<... std ror dirs ...> >> /var/www/ROR_App1/gems/ ... >> >> this gems dir will be used as overlay, so somehow it needs to be >> possible to LD_PRELOAD/LD_LIBRARY_PATH this directory (via config in >> apache2/lighty/whereever) >> >> > >>What are you referring to exactly ? Which use case do you have in mind ? >> > > >> > >It's my understanding that gems produces one complete package (gem) with >> > >all Ruby libs needed to run the application and that there is no internal >> > >notion of versioning. >> > >> > Think of gem as a source package that generates binary packages on the >> > fly. It has notions of build dependencies with other gems (including >> > versioning) and run dependencies. >> > >> > One thing it can do is manage several versions of the same gem on the >> > machine at the same time. >> > >> > For example the Rails gem depends upon the rake, activesupport, >> > activerecord, actionpack, actionmailer and actionresource gems. You >> > can install multiple different versions (usually one of each minor >> > revision - 1.2.6, 2.0.2 and 2.1.0) and gem will ensure that the >> > correct versions of the dependent gems are brought in at run time. >> >> As long as gems are only delivering their own binaries... >> But gems are much more, you can include complete (one or more) upstream >> packages (I had this at one ocasion, there was this imagemagick gem and >> this module was only working with a special imagemagick version, so it >> shipped it together with the other cruft, but instead of installing it >> somewhere where this imagemagick lib didn't hurt, it was just a smartass >> and installed it in /usr/lib, overwriting the distro imagemagick). >This is a good example of that, and it happens on more than just debian >systems. I do however feel that Neils proposed change(s) to the gems >package has the best intrest in mind without major changes to gem and >apt. This is a step forward, no? I think that if gem was installing dependencies in a location that would not interfere (e.g. be used instead of) installed system libraries, but that the installed Gem could use the I could say yes to this. Scott K -- Ubuntu-motu mailing list Ubuntu-motu@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu
Re: Ruby on Rails support in Intrepid - call for reviewers and cheerleaders
On Wed, 2008-08-20 at 15:31 +0200, Stephan Hermann wrote: > On Wed, Aug 20, 2008 at 02:07:46PM +0100, Neil Wilson wrote: > > Scott, > > > > I'm trying to avoid the wheres and wherefores of what gem is about. > > Suffice to say that Rails depends upon effective gem support, such > > that the configuration of Rails can specify gem dependencies directly. > > > > So if Ubuntu wants Rails, it has to have Gem that works. Therefore I > > saw my task as trying to get gem to work as a user would expect it to > > work without gem destroying the operating system, leaving cruft lying > > around the filesystem in the wrong place and try and prevent it > > running into itself too much > > > > It's an exercise in containment. > > What about teaching ROR to use an overlay, especially for the webapp you > code for? > > I mean, the problem with gem is known...it's nasty... > afaik gem can do something like a destdir install somehow (when I'm not > mistaken and my mind is working in normal parameters, and my knowledge > from old ROR times is still valid). > If you have such a structure: > > /var/www/ROR_App1/<... std ror dirs ...> > /var/www/ROR_App1/gems/ ... > > this gems dir will be used as overlay, so somehow it needs to be > possible to LD_PRELOAD/LD_LIBRARY_PATH this directory (via config in > apache2/lighty/whereever) > > > >>What are you referring to exactly ? Which use case do you have in mind ? > > > > > >It's my understanding that gems produces one complete package (gem) with > > >all Ruby libs needed to run the application and that there is no internal > > >notion of versioning. > > > > Think of gem as a source package that generates binary packages on the > > fly. It has notions of build dependencies with other gems (including > > versioning) and run dependencies. > > > > One thing it can do is manage several versions of the same gem on the > > machine at the same time. > > > > For example the Rails gem depends upon the rake, activesupport, > > activerecord, actionpack, actionmailer and actionresource gems. You > > can install multiple different versions (usually one of each minor > > revision - 1.2.6, 2.0.2 and 2.1.0) and gem will ensure that the > > correct versions of the dependent gems are brought in at run time. > > As long as gems are only delivering their own binaries... > But gems are much more, you can include complete (one or more) upstream > packages (I had this at one ocasion, there was this imagemagick gem and > this module was only working with a special imagemagick version, so it > shipped it together with the other cruft, but instead of installing it > somewhere where this imagemagick lib didn't hurt, it was just a smartass > and installed it in /usr/lib, overwriting the distro imagemagick). This is a good example of that, and it happens on more than just debian systems. I do however feel that Neils proposed change(s) to the gems package has the best intrest in mind without major changes to gem and apt. This is a step forward, no? David P. macd(on)freenode > > This gem package didn't respect: DESTDIR, neither it respected the > ./configure --prefix=<...> commands...so it destroyed other apps...but > this wasn't documented anywhere, btw. > > so, having an overlay dir, where those gems can be installed without > disturbing the other software, fine...but not as it is now, and not > installing their stuff into /usr/local/lib or into /opt/foo > > Regards, > \sh > > -- > Stephan '\sh' Hermann | OSS Developer & Systemadministrator > JID: [EMAIL PROTECTED]| http://www.sourcecode.de/ > GPG ID: 0xC098EFA8| http://leonov.tv/ > 3D8B 5138 0852 DA7A B83F DCCB C189 E733 C098 EFA8 > -- Ubuntu-motu mailing list Ubuntu-motu@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu
Re: Ruby on Rails support in Intrepid - call for reviewers and cheerleaders
On Wed, Aug 20, 2008 at 02:07:46PM +0100, Neil Wilson wrote: > Scott, > > I'm trying to avoid the wheres and wherefores of what gem is about. > Suffice to say that Rails depends upon effective gem support, such > that the configuration of Rails can specify gem dependencies directly. > > So if Ubuntu wants Rails, it has to have Gem that works. Therefore I > saw my task as trying to get gem to work as a user would expect it to > work without gem destroying the operating system, leaving cruft lying > around the filesystem in the wrong place and try and prevent it > running into itself too much > > It's an exercise in containment. What about teaching ROR to use an overlay, especially for the webapp you code for? I mean, the problem with gem is known...it's nasty... afaik gem can do something like a destdir install somehow (when I'm not mistaken and my mind is working in normal parameters, and my knowledge from old ROR times is still valid). If you have such a structure: /var/www/ROR_App1/<... std ror dirs ...> /var/www/ROR_App1/gems/ ... this gems dir will be used as overlay, so somehow it needs to be possible to LD_PRELOAD/LD_LIBRARY_PATH this directory (via config in apache2/lighty/whereever) > >>What are you referring to exactly ? Which use case do you have in mind ? > > > >It's my understanding that gems produces one complete package (gem) with > >all Ruby libs needed to run the application and that there is no internal > >notion of versioning. > > Think of gem as a source package that generates binary packages on the > fly. It has notions of build dependencies with other gems (including > versioning) and run dependencies. > > One thing it can do is manage several versions of the same gem on the > machine at the same time. > > For example the Rails gem depends upon the rake, activesupport, > activerecord, actionpack, actionmailer and actionresource gems. You > can install multiple different versions (usually one of each minor > revision - 1.2.6, 2.0.2 and 2.1.0) and gem will ensure that the > correct versions of the dependent gems are brought in at run time. As long as gems are only delivering their own binaries... But gems are much more, you can include complete (one or more) upstream packages (I had this at one ocasion, there was this imagemagick gem and this module was only working with a special imagemagick version, so it shipped it together with the other cruft, but instead of installing it somewhere where this imagemagick lib didn't hurt, it was just a smartass and installed it in /usr/lib, overwriting the distro imagemagick). This gem package didn't respect: DESTDIR, neither it respected the ./configure --prefix=<...> commands...so it destroyed other apps...but this wasn't documented anywhere, btw. so, having an overlay dir, where those gems can be installed without disturbing the other software, fine...but not as it is now, and not installing their stuff into /usr/local/lib or into /opt/foo Regards, \sh -- Stephan '\sh' Hermann | OSS Developer & Systemadministrator JID: [EMAIL PROTECTED] | http://www.sourcecode.de/ GPG ID: 0xC098EFA8 | http://leonov.tv/ 3D8B 5138 0852 DA7A B83F DCCB C189 E733 C098 EFA8 -- Ubuntu-motu mailing list Ubuntu-motu@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu
Re: Ruby on Rails support in Intrepid - call for reviewers and cheerleaders
Scott, I'm trying to avoid the wheres and wherefores of what gem is about. Suffice to say that Rails depends upon effective gem support, such that the configuration of Rails can specify gem dependencies directly. So if Ubuntu wants Rails, it has to have Gem that works. Therefore I saw my task as trying to get gem to work as a user would expect it to work without gem destroying the operating system, leaving cruft lying around the filesystem in the wrong place and try and prevent it running into itself too much It's an exercise in containment. >>What are you referring to exactly ? Which use case do you have in mind ? > >It's my understanding that gems produces one complete package (gem) with >all Ruby libs needed to run the application and that there is no internal >notion of versioning. Think of gem as a source package that generates binary packages on the fly. It has notions of build dependencies with other gems (including versioning) and run dependencies. One thing it can do is manage several versions of the same gem on the machine at the same time. For example the Rails gem depends upon the rake, activesupport, activerecord, actionpack, actionmailer and actionresource gems. You can install multiple different versions (usually one of each minor revision - 1.2.6, 2.0.2 and 2.1.0) and gem will ensure that the correct versions of the dependent gems are brought in at run time. So it's not all downside. > This sounds very like Windows DLL hell. It can be, but in reality you don't generally have a problem. For the most part the system works - until you start uninstalling, upgrading the operating system or changing interpreter versions. > It does sound like progress. As long as we aren't actually packaing the > gems themselves it seems like a reasonable way to go until Ruby Gems grows > enough features to support proper integration of gems into the distro > package space. Debian has attempted to package some gems, and the results are really not very useful from a Rails point of view. The packages don't tell the gem database that apt has installed something. So gem just reinstalls it. The classic example is the Rake package which is always overridden if somebody does 'gem install rails'. Making apt and gem work better together is something for the future though. -- Neil Wilson -- Ubuntu-motu mailing list Ubuntu-motu@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu
Re: Ruby on Rails support in Intrepid - call for reviewers and cheerleaders
On Tue, Aug 19, 2008 at 02:01:26PM -0700, Mathias Gug wrote: > What are you referring to by package ? > > The make a parallel with python, the gem command is similar to easy_intall. And ezinstall is broken by design for a binary distro and for endusers. ezinstall doesn't check if there is the correct version somehow installed, but downloads from questionable sources (!) .egg files. Most likely we (as packagers) are patching this away. > Neil's proposal is to improve the gem command (from the libgems-ruby > package) so that binaries are installed in /usr/local/bin (thus they're > on the default path). If you'd use install gems from the upstream > source, binaries would be installed in /usr/bin/. The goal is that gems > installed by the gem command don't interfere with ruby libraries and > binaries installed by debian packages. Don't Use Another Package System Then The One From The Distro ! Gem is just another broken package management system for ruby. Pear is just another broken package management system for php. ez_install is just another broken design fullfill dependency management system for python. I think there are others I forgot to mention. Gem packages are even more dangerous because they are delivering sometimes also binaries...which can break your current installation of the stable distro you use. Everytime I have developers in my real life work who are trying to convince me to use this system, I rather try to let them stay in front of a wall and do the chinese way of getting rid of those devs. Mostly I'll go and try to package it in a sane way, the way of my used distro. It will be more difficult but it helps the user and in this case mostly the user is the sysadmin. Developer, who are in need of the newest crack for their development can use gem or pear or ez-install without being unhappy when they destroy their system, they are developer, and they should know what they are doing. (Today this is difficult to say, because most developers don't have a clue what they are doing anyways, only when they are involved in distro specific workflows they know about the problems). I think we don't need another way of handling gem, we just need the time to package all this broken gem crack.. \sh -- Stephan '\sh' Hermann | OSS Developer & Systemadministrator JID: [EMAIL PROTECTED] | http://www.sourcecode.de/ GPG ID: 0xC098EFA8 | http://leonov.tv/ 3D8B 5138 0852 DA7A B83F DCCB C189 E733 C098 EFA8 -- Ubuntu-motu mailing list Ubuntu-motu@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu
Re: Ruby on Rails support in Intrepid - call for reviewers and cheerleaders
Scott Kitterman wrote: > For a legalistic reading of policy, I think there is nothing wrong with that, > but how is a typical user of a gem going to know that if they install gem X a > library used by gem Y, Z, and package A will be replaced/overridden? As a > practical matter I think this declares it all to be the sysadmin's problem > without giving them a way to know what risk they are taking or how to manage > it. > > As I said in an earlier message in the thread it seems very like Windows DLL > hell. Hopefully it will mature. I doubt that as a distro we can do much to > improve this where it is now. Indeed. The use of gems in this way on an end-user system is bound to create problems, of the same sort (as previously pointed out) of end-user use of cpan, ezinstall or maven. That said, policy specifically doesn't forbid the use of such tools by end-users, and we do have support for upstream behaviour for all of cpan, ezinstall, and maven. Creating correct upstream behaviour for gems as well, in a manner that doesn't damage the areas typically managed by the packaging system, is a good thing. Of course, such support cannot be used to build policy-compliant packages, and so any gem that is packaged and has dependencies will require either a patched gem install to handle it, or an alternate build system to be put in place. Ideally, for a given release, all interesting gems would be packaged and be immediately available for use: further users would be encouraged to use the gems from the repositories (as is done for perl, python and Java). -- Emmet HIKORY -- Ubuntu-motu mailing list Ubuntu-motu@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu
Re: Ruby on Rails support in Intrepid - call for reviewers and cheerleaders
On Tuesday 19 August 2008 19:56, Mathias Gug wrote: > On Tue, Aug 19, 2008 at 07:28:02PM -0400, Scott Kitterman wrote: > > >On Tue, Aug 19, 2008 at 05:58:39PM -0400, Scott Kitterman wrote: ... > > >> >Neil's proposal is to improve the gem command (from the libgems-ruby > > >> >package) so that binaries are installed in /usr/local/bin (thus > > >> > they're on the default path). If you'd use install gems from the > > >> > upstream source, binaries would be installed in /usr/bin/. The goal > > >> > is that gems installed by the gem command don't interfere with ruby > > >> > libraries and binaries installed by debian packages. > > >> > > >> Do you mean NOT on the default path then? > > > > > >No. The binaries included in the gem are installed in /usr/local/bin/, > > >which is on the default PATH. > > > > Doesn't that mean they'll get used in place of installed system packages? > > See my comment below. > > > >> >Upstream provided the necessary hooks to do so and Neil used the > > >> >update-alternatives system to handle multiple version of gems being > > >> >installed in /usr/local/bin/ rather than /usr/bin/. > > >> > > >> It does sound like progress. As long as we aren't actually packaing > > >> the gems themselves it seems like a reasonable way to go until Ruby > > >> Gems > > > > grows > > > > >> enough features to support proper integration of gems into the distro > > >> package space. > > > > > >Exactly. Neil's proposal is *not* aimed at integrating gems with the > > >distro package space but rather improve gem installation from source so > > >that it doesn't conflict with distro packages. Proper integration is a > > >long-term goal and we're looking at the Intrepid timeframe. > > > > > >The current rubygem package provides a gem command that installs gem > > >binaries in /var/lib/rubyX.Y/bin/ which is not part of the default PATH. > > >Neil's proposal uses update-alternative to make these binaries available > > >in /usr/loca/bin/ so that they're located in the default PATH. End > > >users won't have to modify their environment and gems will work OOTB. > > > > I can see how this doesn't conflict from an installation perspective, but > > unless I misremember where that is in the path, it will be used in place > > of anything provided through the distro. Am I missing something? > > Nope - you're right. Binaries installed by the gem command will be used > in place of binaries provided by packages since /usr/local/bin comes > first on the PATH. > > I assume that users installing gems from source (ie with the gem > command) want to use the upstream version of the gem rather than the one > provided by the distro. Using the gem command to install from source can > be viewed as a local customization of the system by the system > administrator - thus the usage of /usr/local/bin/. For a legalistic reading of policy, I think there is nothing wrong with that, but how is a typical user of a gem going to know that if they install gem X a library used by gem Y, Z, and package A will be replaced/overridden? As a practical matter I think this declares it all to be the sysadmin's problem without giving them a way to know what risk they are taking or how to manage it. As I said in an earlier message in the thread it seems very like Windows DLL hell. Hopefully it will mature. I doubt that as a distro we can do much to improve this where it is now. Scott K -- Ubuntu-motu mailing list Ubuntu-motu@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu
Re: Ruby on Rails support in Intrepid - call for reviewers and cheerleaders
On Tue, Aug 19, 2008 at 07:28:02PM -0400, Scott Kitterman wrote: > >On Tue, Aug 19, 2008 at 05:58:39PM -0400, Scott Kitterman wrote: > >> Which we generally patch into submission when we find it. In > Debian/Ubuntu > >> if ezsetup is installing external Python modules it's bug. > > > >Do you mean that ezsetup tries to install debian packages of the python > >modules ? > > No ezsetup tries to download and install modules from outside the packaging > system. Ideally we'd patch that out and the provide proper dependencies to > proper packages through the package management system. IIUC, if ezsetup is used by the upstream source file during the build phase and downloads an external python module, that portion is replaced with proper dependencies when creating the package for Debian/Ubuntu. In the case of the gem command, there isn't any interaction with the package system. > >> >Neil's proposal is to improve the gem command (from the libgems-ruby > >> >package) so that binaries are installed in /usr/local/bin (thus they're > >> >on the default path). If you'd use install gems from the upstream > >> >source, binaries would be installed in /usr/bin/. The goal is that gems > >> >installed by the gem command don't interfere with ruby libraries and > >> >binaries installed by debian packages. > >> > >> Do you mean NOT on the default path then? > > > >No. The binaries included in the gem are installed in /usr/local/bin/, > >which is on the default PATH. > > Doesn't that mean they'll get used in place of installed system packages? > See my comment below. > >> >Upstream provided the necessary hooks to do so and Neil used the > >> >update-alternatives system to handle multiple version of gems being > >> >installed in /usr/local/bin/ rather than /usr/bin/. > >> > > >> It does sound like progress. As long as we aren't actually packaing the > >> gems themselves it seems like a reasonable way to go until Ruby Gems > grows > >> enough features to support proper integration of gems into the distro > >> package space. > > > >Exactly. Neil's proposal is *not* aimed at integrating gems with the > >distro package space but rather improve gem installation from source so > >that it doesn't conflict with distro packages. Proper integration is a > >long-term goal and we're looking at the Intrepid timeframe. > > > >The current rubygem package provides a gem command that installs gem > >binaries in /var/lib/rubyX.Y/bin/ which is not part of the default PATH. > >Neil's proposal uses update-alternative to make these binaries available > >in /usr/loca/bin/ so that they're located in the default PATH. End > >users won't have to modify their environment and gems will work OOTB. > > > I can see how this doesn't conflict from an installation perspective, but > unless I misremember where that is in the path, it will be used in place of > anything provided through the distro. Am I missing something? > Nope - you're right. Binaries installed by the gem command will be used in place of binaries provided by packages since /usr/local/bin comes first on the PATH. I assume that users installing gems from source (ie with the gem command) want to use the upstream version of the gem rather than the one provided by the distro. Using the gem command to install from source can be viewed as a local customization of the system by the system administrator - thus the usage of /usr/local/bin/. -- Mathias Gug Ubuntu Developer http://www.ubuntu.com -- Ubuntu-motu mailing list Ubuntu-motu@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu
Re: Ruby on Rails support in Intrepid - call for reviewers and cheerleaders
On Tue, 19 Aug 2008 15:46:34 -0700 Mathias Gug <[EMAIL PROTECTED]> wrote: > >On Tue, Aug 19, 2008 at 05:58:39PM -0400, Scott Kitterman wrote: >> On Tue, 19 Aug 2008 14:01:26 -0700 Mathias Gug <[EMAIL PROTECTED]> wrote: ... >> >The make a parallel with python, the gem command is similar to >> easy_install. >> >> Which we generally patch into submission when we find it. In Debian/Ubuntu >> if ezsetup is installing external Python modules it's bug. > >Do you mean that ezsetup tries to install debian packages of the python >modules ? No ezsetup tries to download and install modules from outside the packaging system. Ideally we'd patch that out and the provide proper dependencies to proper packages through the package management system. >> >Neil's proposal is to improve the gem command (from the libgems-ruby >> >package) so that binaries are installed in /usr/local/bin (thus they're >> >on the default path). If you'd use install gems from the upstream >> >source, binaries would be installed in /usr/bin/. The goal is that gems >> >installed by the gem command don't interfere with ruby libraries and >> >binaries installed by debian packages. >> >> Do you mean NOT on the default path then? > >No. The binaries included in the gem are installed in /usr/local/bin/, >which is on the default PATH. Doesn't that mean they'll get used in place of installed system packages? >> >Upstream provided the necessary hooks to do so and Neil used the >> >update-alternatives system to handle multiple version of gems being >> >installed in /usr/local/bin/ rather than /usr/bin/. >> > >> It does sound like progress. As long as we aren't actually packaing the >> gems themselves it seems like a reasonable way to go until Ruby Gems grows >> enough features to support proper integration of gems into the distro >> package space. > >Exactly. Neil's proposal is *not* aimed at integrating gems with the >distro package space but rather improve gem installation from source so >that it doesn't conflict with distro packages. Proper integration is a >long-term goal and we're looking at the Intrepid timeframe. > >The current rubygem package provides a gem command that installs gem >binaries in /var/lib/rubyX.Y/bin/ which is not part of the default PATH. >Neil's proposal uses update-alternative to make these binaries available >in /usr/loca/bin/ so that they're located in the default PATH. End >users won't have to modify their environment and gems will work OOTB. > I can see how this doesn't conflict from an installation perspective, but unless I misremember where that is in the path, it will be used in place of anything provided through the distro. Am I missing something? Scott K -- Ubuntu-motu mailing list Ubuntu-motu@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu
Re: Ruby on Rails support in Intrepid - call for reviewers and cheerleaders
On Tue, Aug 19, 2008 at 05:58:39PM -0400, Scott Kitterman wrote: > On Tue, 19 Aug 2008 14:01:26 -0700 Mathias Gug <[EMAIL PROTECTED]> wrote: > >On Tue, Aug 19, 2008 at 03:15:15PM -0400, Scott Kitterman wrote: > >> On Tuesday 19 August 2008 15:11, Neil Wilson wrote: > >> > >> > Rubygems contains 'gem' - the Ruby Package manager. Ruby on Rails is a > >> > gem based framework and is completely integrated with the gem package > >> > manager. In Intrepid I would expect users to continue to use gem to > >> > install Rails and for that to be feasible we need a Rubygems package > >> > that works as people expect it to work. I have implemented a patch > >> > that uses the alternatives system so that we can have gem install > >> > binaries in the $PATH without gem and apt running into each other and > >> > without violating Debian policy. This will close a long standing bug > >> > (https://bugs.edge.launchpad.net/ubuntu/+bug/145267). > >> > > > >> I think the answer (as Python has largely learned and Java is learning) > is you > >> have to have a system that will let a package use the installed system > >> libraries and not try and work around the package management system? > > > >What are you referring to by package ? > > > >The make a parallel with python, the gem command is similar to > easy_install. > > Which we generally patch into submission when we find it. In Debian/Ubuntu > if ezsetup is installing external Python modules it's bug. Do you mean that ezsetup tries to install debian packages of the python modules ? > >Neil's proposal is to improve the gem command (from the libgems-ruby > >package) so that binaries are installed in /usr/local/bin (thus they're > >on the default path). If you'd use install gems from the upstream > >source, binaries would be installed in /usr/bin/. The goal is that gems > >installed by the gem command don't interfere with ruby libraries and > >binaries installed by debian packages. > > Do you mean NOT on the default path then? No. The binaries included in the gem are installed in /usr/local/bin/, which is on the default PATH. > >Upstream provided the necessary hooks to do so and Neil used the > >update-alternatives system to handle multiple version of gems being > >installed in /usr/local/bin/ rather than /usr/bin/. > > > It does sound like progress. As long as we aren't actually packaing the > gems themselves it seems like a reasonable way to go until Ruby Gems grows > enough features to support proper integration of gems into the distro > package space. Exactly. Neil's proposal is *not* aimed at integrating gems with the distro package space but rather improve gem installation from source so that it doesn't conflict with distro packages. Proper integration is a long-term goal and we're looking at the Intrepid timeframe. The current rubygem package provides a gem command that installs gem binaries in /var/lib/rubyX.Y/bin/ which is not part of the default PATH. Neil's proposal uses update-alternative to make these binaries available in /usr/loca/bin/ so that they're located in the default PATH. End users won't have to modify their environment and gems will work OOTB. -- Mathias Gug Ubuntu Developer http://www.ubuntu.com -- Ubuntu-motu mailing list Ubuntu-motu@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu
Re: Ruby on Rails support in Intrepid - call for reviewers and cheerleaders
On Tue, 19 Aug 2008 14:01:26 -0700 Mathias Gug <[EMAIL PROTECTED]> wrote: > >On Tue, Aug 19, 2008 at 03:15:15PM -0400, Scott Kitterman wrote: >> On Tuesday 19 August 2008 15:11, Neil Wilson wrote: >> >> > Rubygems contains 'gem' - the Ruby Package manager. Ruby on Rails is a >> > gem based framework and is completely integrated with the gem package >> > manager. In Intrepid I would expect users to continue to use gem to >> > install Rails and for that to be feasible we need a Rubygems package >> > that works as people expect it to work. I have implemented a patch >> > that uses the alternatives system so that we can have gem install >> > binaries in the $PATH without gem and apt running into each other and >> > without violating Debian policy. This will close a long standing bug >> > (https://bugs.edge.launchpad.net/ubuntu/+bug/145267). >> > >> > I've been working closely with the Rubygems upstream team and the >> > package is based on the latest source code from their repository which >> > will be released as Rubygems 1.3.0 very shortly. Getting this into >> > Intrepid will mean that it has the very latest Rubygems containing >> > User based gem support, which is required so that Rails' automatic gem >> > installation tasks work correctly. >> >> Does it have any notion of versions yet? > >What are you referring to exactly ? Which use case do you have in mind ? It's my understanding that gems produces one complete package (gem) with all Ruby libs needed to run the application and that there is no internal notion of versioning. >> If one has two different gems that use the same binaries how does that work? > >Binaries are installed in /usr/local/bin using update-alternatives. The >last installed gems wins. This sounds very like Windows DLL hell. >> I think the answer (as Python has largely learned and Java is learning) is you >> have to have a system that will let a package use the installed system >> libraries and not try and work around the package management system? > >What are you referring to by package ? > >The make a parallel with python, the gem command is similar to easy_install. Which we generally patch into submission when we find it. In Debian/Ubuntu if ezsetup is installing external Python modules it's bug. >Neil's proposal is to improve the gem command (from the libgems-ruby >package) so that binaries are installed in /usr/local/bin (thus they're >on the default path). If you'd use install gems from the upstream >source, binaries would be installed in /usr/bin/. The goal is that gems >installed by the gem command don't interfere with ruby libraries and >binaries installed by debian packages. Do you mean NOT on the default path then? >Upstream provided the necessary hooks to do so and Neil used the >update-alternatives system to handle multiple version of gems being >installed in /usr/local/bin/ rather than /usr/bin/. > It does sound like progress. As long as we aren't actually packaing the gems themselves it seems like a reasonable way to go until Ruby Gems grows enough features to support proper integration of gems into the distro package space. Sc -- Ubuntu-motu mailing list Ubuntu-motu@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu
Re: Ruby on Rails support in Intrepid - call for reviewers and cheerleaders
On Tue, Aug 19, 2008 at 03:15:15PM -0400, Scott Kitterman wrote: > On Tuesday 19 August 2008 15:11, Neil Wilson wrote: > > > Rubygems contains 'gem' - the Ruby Package manager. Ruby on Rails is a > > gem based framework and is completely integrated with the gem package > > manager. In Intrepid I would expect users to continue to use gem to > > install Rails and for that to be feasible we need a Rubygems package > > that works as people expect it to work. I have implemented a patch > > that uses the alternatives system so that we can have gem install > > binaries in the $PATH without gem and apt running into each other and > > without violating Debian policy. This will close a long standing bug > > (https://bugs.edge.launchpad.net/ubuntu/+bug/145267). > > > > I've been working closely with the Rubygems upstream team and the > > package is based on the latest source code from their repository which > > will be released as Rubygems 1.3.0 very shortly. Getting this into > > Intrepid will mean that it has the very latest Rubygems containing > > User based gem support, which is required so that Rails' automatic gem > > installation tasks work correctly. > > Does it have any notion of versions yet? What are you referring to exactly ? Which use case do you have in mind ? > If one has two different gems that use the same binaries how does that work? Binaries are installed in /usr/local/bin using update-alternatives. The last installed gems wins. > I think the answer (as Python has largely learned and Java is learning) is > you > have to have a system that will let a package use the installed system > libraries and not try and work around the package management system? What are you referring to by package ? The make a parallel with python, the gem command is similar to easy_intall. Neil's proposal is to improve the gem command (from the libgems-ruby package) so that binaries are installed in /usr/local/bin (thus they're on the default path). If you'd use install gems from the upstream source, binaries would be installed in /usr/bin/. The goal is that gems installed by the gem command don't interfere with ruby libraries and binaries installed by debian packages. Upstream provided the necessary hooks to do so and Neil used the update-alternatives system to handle multiple version of gems being installed in /usr/local/bin/ rather than /usr/bin/. -- Mathias Gug Ubuntu Developer http://www.ubuntu.com -- Ubuntu-motu mailing list Ubuntu-motu@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu
Re: Ruby on Rails support in Intrepid - call for reviewers and cheerleaders
On Tuesday 19 August 2008 15:11, Neil Wilson wrote: > Rubygems contains 'gem' - the Ruby Package manager. Ruby on Rails is a > gem based framework and is completely integrated with the gem package > manager. In Intrepid I would expect users to continue to use gem to > install Rails and for that to be feasible we need a Rubygems package > that works as people expect it to work. I have implemented a patch > that uses the alternatives system so that we can have gem install > binaries in the $PATH without gem and apt running into each other and > without violating Debian policy. This will close a long standing bug > (https://bugs.edge.launchpad.net/ubuntu/+bug/145267). > > I've been working closely with the Rubygems upstream team and the > package is based on the latest source code from their repository which > will be released as Rubygems 1.3.0 very shortly. Getting this into > Intrepid will mean that it has the very latest Rubygems containing > User based gem support, which is required so that Rails' automatic gem > installation tasks work correctly. Does it have any notion of versions yet? If one has two different gems that use the same binaries how does that work? I think the answer (as Python has largely learned and Java is learning) is you have to have a system that will let a package use the installed system libraries and not try and work around the package management system? Scott K -- Ubuntu-motu mailing list Ubuntu-motu@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu
