Gems again; signing records
I know this has been asked before but his is driving me nuts.It' s been a frustrating day; I've been trying to use the UUID gem and have still not been able to 'require' it successfully. I have installed uuid using macgem and have unpacked it to a vendor directory, so I now have : vendor -- macaddr-1.0.0 -- lib -- macaddr.rb -- uuid-2.3.1 -- lib -- uuid.rb Obviously, there's more, but those are important bits. I have tried the following, after googling, with no success, on the basis that the files are 'require'd and once loaded, can be 'require'd again by simple reference: In rb_main.rb $:.unshift File.join(File.dirname(__FILE__), 'Vendor/uuid-2.3.1/lib') $:.unshift File.join(File.dirname(__FILE__), 'Vendor/macaddr-1.0.0/ lib') require 'macaddr' require 'uuid' However, when I try to require 'macaddr' or 'uuid' from another class definition file, I get 'no such file to load'. I've tried setting ENV['GEM_HOME']='/Users/martin/work/macruby/onWeb/ PeepOpen/Vendor' in rb_main.rb; that seemed to make no difference. I've tried using the full path: require '/Users/martin/work/macruby/onWeb/xxxxxx/Vendor/macaddr-1.0.0/ lib/macaddr' require '/Users/martin/work/macruby/onWeb/xxxxxx/Vendor/uuid-2.3.1/lib/ uuid' and this produces a 'no such file to load -- fileutils' - neither gem depends on fileutils ! But hey, I tried it and it refused to build - 'checking for Magick- config... no' So I have two questions: 1. What is the *proper* way of incorporating gems into a MacRuby project using XCode to build and run; and 2. All I want to do is sign records for later comparison. Can anybody suggest an alternative method, other than using UUID? thanks
On Fri, Jan 28, 2011 at 12:41 PM, Martin Hawkins <martin.hawkins@gmail.com>wrote:
In rb_main.rb
$:.unshift File.join(File.dirname(__FILE__), 'Vendor/uuid-2.3.1/lib') $:.unshift File.join(File.dirname(__FILE__), 'Vendor/macaddr-1.0.0/ lib')
require 'macaddr' require 'uuid'
However, when I try to require 'macaddr' or 'uuid' from another class definition file, I get 'no such file to load'.
Two things: -- You should only have to require these files once, unless you expect the other class definitions to be used independently of your main project. Putting these in rb_main.rb is typically a good idea. -- This might be obvious, but just in case: the "File.join(File.dirname..." patern will only work in rb_main.rb or any other file in the same directory. If you've put your class definition files in lib/ then you'll need to change the relative path.
1. What is the *proper* way of incorporating gems into a MacRuby project using XCode to build and run; and
Typically, when you unpack a gem it will have a structure like: /foo_gem-1.0/lib /foo_gem-1.0/lib/foo_gem.rb /foo_gem-1.0/lib/foo_gem/library_files.rb In other words, usually the "lib" directory is already partitioned by gem name inside the gem. So, what I do is to just collect all the contents of the "lib" directories for all the gems and put them together (either directly in my own lib/ or in vendor/lib/). There's no reason for the extra directories...just adds complexity.
2. All I want to do is sign records for later comparison. Can anybody suggest an alternative method, other than using UUID?
In MacRuby you can use the CFUUID utilities: http://developer.apple.com/library/mac/#documentation/CoreFoundation/Referen...
macirb irb(main):001:0> framework 'Foundation' => true irb(main):002:0> cfuuid = CFUUIDCreate(nil) => #<__NSCFType:0x200f6dd60> irb(main):003:0> id = CFUUIDCreateString(nil, cfuuid) => "689369A5-5CCD-41D0-BF83-1759BFD4F3EA" irb(main):004:0> CFRelease(cfuuid) => nil
Well, I've just realised that get the fileutils message was in fact a sign of some success, as the UUID gem does indeed require it. I'll play around a little more with gem loading - I've got to get it right for other projects. I was doing what you suggested but without apparent success. wrt CFUUID, that's helpful and I'll look at that. I was just looking at NSProcessInfo, which has a globallyUniqueString method. On Jan 28, 6:25 pm, Joshua Ballanco <jball...@gmail.com> wrote:
On Fri, Jan 28, 2011 at 12:41 PM, Martin Hawkins <martin.hawk...@gmail.com>wrote:
In rb_main.rb
$:.unshift File.join(File.dirname(__FILE__), 'Vendor/uuid-2.3.1/lib') $:.unshift File.join(File.dirname(__FILE__), 'Vendor/macaddr-1.0.0/ lib')
require 'macaddr' require 'uuid'
However, when I try to require 'macaddr' or 'uuid' from another class definition file, I get 'no such file to load'.
Two things:
-- You should only have to require these files once, unless you expect the other class definitions to be used independently of your main project. Putting these in rb_main.rb is typically a good idea. -- This might be obvious, but just in case: the "File.join(File.dirname..." patern will only work in rb_main.rb or any other file in the same directory. If you've put your class definition files in lib/ then you'll need to change the relative path.
1. What is the *proper* way of incorporating gems into a MacRuby project using XCode to build and run; and
Typically, when you unpack a gem it will have a structure like:
/foo_gem-1.0/lib /foo_gem-1.0/lib/foo_gem.rb /foo_gem-1.0/lib/foo_gem/library_files.rb
In other words, usually the "lib" directory is already partitioned by gem name inside the gem. So, what I do is to just collect all the contents of the "lib" directories for all the gems and put them together (either directly in my own lib/ or in vendor/lib/). There's no reason for the extra directories...just adds complexity.
2. All I want to do is sign records for later comparison. Can anybody suggest an alternative method, other than using UUID?
In MacRuby you can use the CFUUID utilities:http://developer.apple.com/library/mac/#documentation/CoreFoundation/...
macirb
irb(main):001:0> framework 'Foundation' => true irb(main):002:0> cfuuid = CFUUIDCreate(nil) => #<__NSCFType:0x200f6dd60> irb(main):003:0> id = CFUUIDCreateString(nil, cfuuid) => "689369A5-5CCD-41D0-BF83-1759BFD4F3EA" irb(main):004:0> CFRelease(cfuuid) => nil
_______________________________________________ MacRuby-devel mailing list MacRuby-de...@lists.macosforge.orghttp://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
Hi Martin, I think we now get the "how to embed gems in a MacRuby Xcode project?" question every week. I think it's time that we provide a way to automate that and properly document it on the website. As I suggested on IRC yesterday, I think we should add a --gem argument to macruby_deploy, which would make sure the given gems and their dependencies are unpacked inside the application bundle. I created the following ticket to track this change, and I believe it should be done for 0.9. https://www.macruby.org/trac/ticket/1137 Laurent On Jan 28, 2011, at 9:41 AM, Martin Hawkins wrote:
I know this has been asked before but his is driving me nuts.It' s been a frustrating day; I've been trying to use the UUID gem and have still not been able to 'require' it successfully.
I have installed uuid using macgem and have unpacked it to a vendor directory, so I now have : vendor -- macaddr-1.0.0 -- lib -- macaddr.rb -- uuid-2.3.1 -- lib -- uuid.rb
Obviously, there's more, but those are important bits.
I have tried the following, after googling, with no success, on the basis that the files are 'require'd and once loaded, can be 'require'd again by simple reference: In rb_main.rb
$:.unshift File.join(File.dirname(__FILE__), 'Vendor/uuid-2.3.1/lib') $:.unshift File.join(File.dirname(__FILE__), 'Vendor/macaddr-1.0.0/ lib')
require 'macaddr' require 'uuid'
However, when I try to require 'macaddr' or 'uuid' from another class definition file, I get 'no such file to load'.
I've tried setting ENV['GEM_HOME']='/Users/martin/work/macruby/onWeb/ PeepOpen/Vendor' in rb_main.rb; that seemed to make no difference.
I've tried using the full path: require '/Users/martin/work/macruby/onWeb/xxxxxx/Vendor/macaddr-1.0.0/ lib/macaddr' require '/Users/martin/work/macruby/onWeb/xxxxxx/Vendor/uuid-2.3.1/lib/ uuid' and this produces a 'no such file to load -- fileutils' - neither gem depends on fileutils !
But hey, I tried it and it refused to build - 'checking for Magick- config... no'
So I have two questions:
1. What is the *proper* way of incorporating gems into a MacRuby project using XCode to build and run; and 2. All I want to do is sign records for later comparison. Can anybody suggest an alternative method, other than using UUID?
thanks _______________________________________________ MacRuby-devel mailing list MacRuby-devel@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
On 2011-01-28, at 20:30 , Laurent Sansonetti wrote:
As I suggested on IRC yesterday, I think we should add a --gem argument to macruby_deploy, which would make sure the given gems and their dependencies are unpacked inside the application bundle.
It could be great if this involved a bit of magic, so you only specify the gems you need in a single place. Maybe it's overkill, but we could rely on Bundler. I'm a Bundler hater turned devotee. It really helps keep a tight grip on a project's gem dependencies, locking versions and all. With the added benefit to pull gems from custom paths and git repos. I suppose such support could be built on top of a simpler --gem argument in a rake task, though. Anyway, food for thought.
Hi Caio, On Jan 28, 2011, at 2:39 PM, Caio Chassot wrote:
On 2011-01-28, at 20:30 , Laurent Sansonetti wrote:
As I suggested on IRC yesterday, I think we should add a --gem argument to macruby_deploy, which would make sure the given gems and their dependencies are unpacked inside the application bundle.
It could be great if this involved a bit of magic, so you only specify the gems you need in a single place.
Maybe it's overkill, but we could rely on Bundler. I'm a Bundler hater turned devotee. It really helps keep a tight grip on a project's gem dependencies, locking versions and all. With the added benefit to pull gems from custom paths and git repos.
I suppose such support could be built on top of a simpler --gem argument in a rake task, though.
I would rather avoid any dependency. I agree that keeping track of the gems you need in a single place is a good idea, though. Maybe we should refactor the Xcode templates to do so, eventually. Another possibility would be to scan the application's source code and auto-detect the list of gems, but I prefer to avoid that. Laurent
On 2011-01-28, at 21:36 , Laurent Sansonetti wrote:
I would rather avoid any dependency. I agree that keeping track of the gems you need in a single place is a good idea, though.
Maybe we should refactor the Xcode templates to do so, eventually.
I'd classify Xcode as a dependency. Simple plain text files are nice and tidy. And that's what a Gemfile is. We can skip Bundler and just steal the Gemfile format, or a subset of it. It's rather well specified: http://gembundler.com/man/gemfile.5.html
Another possibility would be to scan the application's source code and auto-detect the list of gems, but I prefer to avoid that.
Indeed. So many ways this could go wrong.
IMHO adding Bundler as a dependency would be a huge mistake. First, Bundler code is overly complicated and tries to do way too much. Trying to resolve the dependency tree is not something you should do in prod or on a client machine. This belongs to the dev environment. We could potentially look at isolate but it doesn't support 'frozen' gems. The way I see it, we just need macdeploy to unpack the gems you need & their dependencies as well as modify the loadpath. By doing that our prod apps don't even have the need to load or rely on rubygems. What do you think? - Matt Sent from my iPhone On Jan 28, 2011, at 16:09, Caio Chassot <lists@caiochassot.com> wrote:
On 2011-01-28, at 21:36 , Laurent Sansonetti wrote:
I would rather avoid any dependency. I agree that keeping track of the gems you need in a single place is a good idea, though.
Maybe we should refactor the Xcode templates to do so, eventually.
I'd classify Xcode as a dependency. Simple plain text files are nice and tidy.
And that's what a Gemfile is. We can skip Bundler and just steal the Gemfile format, or a subset of it. It's rather well specified: http://gembundler.com/man/gemfile.5.html
Another possibility would be to scan the application's source code and auto-detect the list of gems, but I prefer to avoid that.
Indeed. So many ways this could go wrong. _______________________________________________ MacRuby-devel mailing list MacRuby-devel@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
On 2011-01-29, at 02:11 , Matt Aimonetti wrote:
IMHO adding Bundler as a dependency would be a huge mistake. First, Bundler code is overly complicated and tries to do way too much.
(You forgot to mention slow.) I think I agree here. I just like the Gemfile format. Don't think we need to reinvent the wheel.
Trying to resolve the dependency tree is not something you should do in prod or on a client machine. This belongs to the dev environment.
Maybe your argument backfires here, because resolving the dependency tree at compile time to decide which gems to bundle in the final app is actually quite useful. In fact, it's what you suggest right after:
The way I see it, we just need macdeploy to unpack the gems you need & their dependencies as well as modify the loadpath. By doing that our prod apps don't even have the need to load or rely on rubygems.
Yes. In fact not loading rubygems on bundled/compiled apps is probably something to strive for. I can see things getting messy with unforeseen conflicts between app gems and user gems.
Yes, what we need is a tool that resolves dependencies at release time and bundle these in the app. The app also have a shim that makes sure that if any of the bundled dependencies call Kernel#gem it doesn't break. I.e. on the clients machine rubygems should not actually be loaded to ensure as fast as possible startup times. When I recently spoke to Yehuda he said that bundler now has a `standalone' feature which provides exactly the aforementioned requirements. I haven't tried it, nor do I suggest we use it, but having written my own dependency resolver in the past, it might be a nice idea to at least try it. @Laurent: Do you know if Rails 3 will be shipped with future OS X updates? If so, bundler probably will come with the system too, so it's not really a problem to depend on it. Especially since you don't *have* to use it if you wish to do it another way. To the rest, I would love to create a patch for this but don't have enough free time atm. So instead of discussing this again and in the end not having anything, I propose somebody that currently needs it and has the time to create a patch that does the described requirements. Only then will we be able to really judge whether or not the full bundler lib is what we need or if we can write our own (or extract) subset of it and continue the discussion from there. On Sat, Jan 29, 2011 at 5:24 AM, Caio Chassot <lists@caiochassot.com> wrote:
On 2011-01-29, at 02:11 , Matt Aimonetti wrote:
IMHO adding Bundler as a dependency would be a huge mistake. First, Bundler code is overly complicated and tries to do way too much.
(You forgot to mention slow.)
I think I agree here. I just like the Gemfile format. Don't think we need to reinvent the wheel.
Trying to resolve the dependency tree is not something you should do in prod or on a client machine. This belongs to the dev environment.
Maybe your argument backfires here, because resolving the dependency tree at compile time to decide which gems to bundle in the final app is actually quite useful. In fact, it's what you suggest right after:
The way I see it, we just need macdeploy to unpack the gems you need & their dependencies as well as modify the loadpath. By doing that our prod apps don't even have the need to load or rely on rubygems.
Yes. In fact not loading rubygems on bundled/compiled apps is probably something to strive for. I can see things getting messy with unforeseen conflicts between app gems and user gems.
_______________________________________________ MacRuby-devel mailing list MacRuby-devel@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
Btw, I don't think a Gemfile adds anything for a bundled production app besides that our shim would have to support the DSL. I think the dev should just use ‘require "bananas"’ in her code and it should just work. I.e. the Gemfile is I think only needed in development and at release time. On Sat, Jan 29, 2011 at 11:08 AM, Eloy Duran <eloy.de.enige@gmail.com> wrote:
Yes, what we need is a tool that resolves dependencies at release time and bundle these in the app. The app also have a shim that makes sure that if any of the bundled dependencies call Kernel#gem it doesn't break. I.e. on the clients machine rubygems should not actually be loaded to ensure as fast as possible startup times.
When I recently spoke to Yehuda he said that bundler now has a `standalone' feature which provides exactly the aforementioned requirements. I haven't tried it, nor do I suggest we use it, but having written my own dependency resolver in the past, it might be a nice idea to at least try it.
@Laurent: Do you know if Rails 3 will be shipped with future OS X updates? If so, bundler probably will come with the system too, so it's not really a problem to depend on it. Especially since you don't *have* to use it if you wish to do it another way.
To the rest, I would love to create a patch for this but don't have enough free time atm. So instead of discussing this again and in the end not having anything, I propose somebody that currently needs it and has the time to create a patch that does the described requirements. Only then will we be able to really judge whether or not the full bundler lib is what we need or if we can write our own (or extract) subset of it and continue the discussion from there.
On Sat, Jan 29, 2011 at 5:24 AM, Caio Chassot <lists@caiochassot.com> wrote:
On 2011-01-29, at 02:11 , Matt Aimonetti wrote:
IMHO adding Bundler as a dependency would be a huge mistake. First, Bundler code is overly complicated and tries to do way too much.
(You forgot to mention slow.)
I think I agree here. I just like the Gemfile format. Don't think we need to reinvent the wheel.
Trying to resolve the dependency tree is not something you should do in prod or on a client machine. This belongs to the dev environment.
Maybe your argument backfires here, because resolving the dependency tree at compile time to decide which gems to bundle in the final app is actually quite useful. In fact, it's what you suggest right after:
The way I see it, we just need macdeploy to unpack the gems you need & their dependencies as well as modify the loadpath. By doing that our prod apps don't even have the need to load or rely on rubygems.
Yes. In fact not loading rubygems on bundled/compiled apps is probably something to strive for. I can see things getting messy with unforeseen conflicts between app gems and user gems.
_______________________________________________ MacRuby-devel mailing list MacRuby-devel@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
It's great to see this discussion. As a developer, I just want to ‘require "bananas"’ and see it work. I come from a Rails background, so I know that gem dependencies can create all sorts of problems. As Macruby becomes more popular, these problems are going to become more apparent as the diversity of gems that people want to utilise grows. macruby_deploy --gem nokogiri --gem rack MyApp.app would be excellent! regards Martin On Jan 29, 10:10 am, Eloy Duran <eloy.de.en...@gmail.com> wrote:
Btw, I don't think a Gemfile adds anything for a bundled production app besides that our shim would have to support the DSL. I think the dev should just use ‘require "bananas"’ in her code and it should just work. I.e. the Gemfile is I think only needed in development and at release time.
On Sat, Jan 29, 2011 at 11:08 AM, Eloy Duran <eloy.de.en...@gmail.com> wrote:
Yes, what we need is a tool that resolves dependencies at release time and bundle these in the app. The app also have a shim that makes sure that if any of the bundled dependencies call Kernel#gem it doesn't break. I.e. on the clients machine rubygems should not actually be loaded to ensure as fast as possible startup times.
When I recently spoke to Yehuda he said that bundler now has a `standalone' feature which provides exactly the aforementioned requirements. I haven't tried it, nor do I suggest we use it, but having written my own dependency resolver in the past, it might be a nice idea to at least try it.
@Laurent: Do you know if Rails 3 will be shipped with future OS X updates? If so, bundler probably will come with the system too, so it's not really a problem to depend on it. Especially since you don't *have* to use it if you wish to do it another way.
To the rest, I would love to create a patch for this but don't have enough free time atm. So instead of discussing this again and in the end not having anything, I propose somebody that currently needs it and has the time to create a patch that does the described requirements. Only then will we be able to really judge whether or not the full bundler lib is what we need or if we can write our own (or extract) subset of it and continue the discussion from there.
On Sat, Jan 29, 2011 at 5:24 AM, Caio Chassot <li...@caiochassot.com> wrote:
On 2011-01-29, at 02:11 , Matt Aimonetti wrote:
IMHO adding Bundler as a dependency would be a huge mistake. First, Bundler code is overly complicated and tries to do way too much.
(You forgot to mention slow.)
I think I agree here. I just like the Gemfile format. Don't think we need to reinvent the wheel.
Trying to resolve the dependency tree is not something you should do in prod or on a client machine. This belongs to the dev environment.
Maybe your argument backfires here, because resolving the dependency tree at compile time to decide which gems to bundle in the final app is actually quite useful. In fact, it's what you suggest right after:
The way I see it, we just need macdeploy to unpack the gems you need & their dependencies as well as modify the loadpath. By doing that our prod apps don't even have the need to load or rely on rubygems.
Yes. In fact not loading rubygems on bundled/compiled apps is probably something to strive for. I can see things getting messy with unforeseen conflicts between app gems and user gems.
_______________________________________________ MacRuby-devel mailing list MacRuby-de...@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
_______________________________________________ MacRuby-devel mailing list MacRuby-de...@lists.macosforge.orghttp://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
participants (6)
-
Caio Chassot
-
Eloy Duran
-
Joshua Ballanco
-
Laurent Sansonetti
-
Martin Hawkins
-
Matt Aimonetti