Chad Woolley wrote: > This sounds like a great start for a plan. However, I wonder about this: > >> I would recommend making the override available for >> only explicitly installed gems (not for gems that are installed >> automatically because they are dependencies). > > What is the reason for this?
Complexity of user interface. If I ask RubyGems to install gem a, which depends on gem b, which in turn depends upon gem c, do I really want to be overriding the platform of gem c? Not really. It is much more straight forward to just install gem c directly, overriding the platform, and then install gem a. > What if a pure-ruby gem has a > platform-specific dependency? Gems don't have platform specific dependencies. They depend upon generic gems that may (or may not) have multiple platform specific variants available. If I am installing a pure ruby gem on my Mac that depends on a gem that is only available on a windows platform, the install of the dependent gem will fail, which will in turn fail the install of the original gem. > The user should be able to override > that. Or, are you assuming that they will have to be aware of the > dependencies, and explicitly pre-install the dependencies with the > correct platform first, before the dependent gem is installed? If the defaults don't work, I don't expect anyone to know that before they try. If a default selection on a dependent gem fails, I would expect the user to explicitly install a gem with an override, then continue with the original install. > - What about legacy gems? Will there be some sort of algorithm to map > pre-existing platforms to the new platform spec? I suspect we should be able to scan the existing gems on RubyForge and migrate them more or less automatically. By far the most common types are pure ruby and C source gems, with a smattering of some binary gems. > - How do you plan to enforce the new platform format? Will there be > specific structures and fields in the gem spec to support the > hierarchy you proposed? What will prevent people from circumventing > this and submitting invalid platforms (if this is possible)? I've not given this part too much thought yet. I suspect the range of hardware designations will have to be somewhat controlled, otherwise you will get a variety of synonyms for the same platform (e.g. "windows" vs "win32" vs "mswin", or even "macos" vs "osx" vs "darwin"). I hope the data from the tottle project will drive the specific designations. I'm just trying to put together a framework for categorizing them. > Thanks for tackling this issue, Thanks. It's a long overdue topic. -- -- Jim Weirich [EMAIL PROTECTED] http://onestepback.org -- In theory, practice and theory are the same. -- In practice, they are different. _______________________________________________ Rubygems-developers mailing list [email protected] http://rubyforge.org/mailman/listinfo/rubygems-developers
