Luis, > Better way to explain this is do it graphically: > > http://gist.github.com/62222
Here are the list of deps for dm-core and dm-more: dm-core: http://gist.github.com/62304 dm-more: http://gist.github.com/62316 One key thing is that I don't expect many people outside of a few DM contributors to actually install the dm-more meta-gem. It's too massive for real-world usage. I would expect most normal users to install only a few of those gems piecemeal. The deps for dm-core itself are pretty simple and "shallow", meaning that the things it depends on don't depend on much else. I'm going to assume for now that dm-core's deps are not the problem. One issue I can see is that in all the dm-more gems we are using ~> to specify the dm-core dep. We should be using "=" until DM 1.0 is released and the API is frozen. Prior to 1.0, we are actively refining the API in every release, and I would only expect all dm-more gems to only work with the *exact* same dm-core version. Another issue is the dm-types dependencies on bcrypt-ruby and json. Someone who installs dm-types may not necessarily be using the bcrypt or json types, yet their dependencies are required to install the whole package. I think Michael Klishin (antares_) removed this dependency. I still worry about the case where someone actually *wants* to use those types, attempts to, and then watches things blow up because the deps weren't installed. I'm not sure there's a clear solution to this, because we can't really determine people's intentions when installing dm-types. Perhaps a policy where we split anything that requires a C extension into it's own package, which in itself may create yet another dependency, but I don't know of another solution that will work in all cases. > There are several ways to resolve this, some are manifest of gems used > and using bundling that exists in merb. Right. I believe there is one issue with merb and the way dm-core attempts to detect which DO gems are installed, requiring them if available. Carl Lerche may be able to provide more detail on this. In the dm-core "next" branch I removed the auto-detection code and made it so DO gems are only required if you do an explicit DataMapper.setup() call. This has the added benefit of reducing DM's memory footprint. I had originally intended to include this feature in the first 0.10.0 release in a month or so, but I could back-port this to dm-core master for the next 0.9 release. > The other is turn smaller gems with similar purposes into bigger ones > (so mentioned flexibility). I suppose this is an option, although there aren't really any gems with similar purposes, afaik they are all split up according to completely different concerns. My intention with dm-core was to make it as slim as possible, so that people could opt-in and require just the gems they want to use. > Cannot provide examples for Merb, but something I found quite often is > the need to remember how many gems I need to install in the servers > (and which versions), either via ssh or automated deploy/bundling. > > An example of going from -core and -more gems back into one is Sequel, > they merged both back when version 2.3.0 came out. Would the use of the "datamapper" meta-gem help? Not many people know about it, but it installs dm-core, and a few of the more popular dm- more gems. It also ensures the correct versions are installed since it uses "=" deps between them. -- Dan (dkubb) --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "DataMapper" group. To post to this group, send email to datamapper@googlegroups.com To unsubscribe from this group, send email to datamapper+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/datamapper?hl=en -~----------~----~----~----~------~----~------~--~---
