----- Original Message -----
> Not sure how you could do a good job having one version of a package
> available by default, and a different one available by requires().
> Eggs list the top level packages provided and you could shadow them
> but it seems like it would be really messy.
>
Yup, it'd require decent amount of changes and probably break some backwards
compatibility as mentioned.
> Ruby Gems appear to have a directory full of gems:
> ~/.gem/ruby/1.8/gems/. Each subdirectory is {name}-{version} and
> doesn't need any suffix - we know what they are because of where they
> are.
>
> bundler-1.2.1
> json-1.7.5
> sinatra-1.3.3
> tilt-1.3.3
> tzinfo-0.3.33
>
> Each subdirectory contains metadata, and a lib/ directory that would
> actually be added to the Ruby module path.
>
Not exactly. the 1.8 directory contains gems/ and specifications/. The
specifications/ directory contain {name}-{version}.gemspec, which is a
meta-information holder for the specific gem. Among other things, it contains
require_paths, that are concatenated with gems/{name}-{versions} to get the
load path. So the rubygems require first looks at the list of specs, then
chooses the proper one (newest when no version is specified or the specified
one) and then computes the load path from it.
> Like with pkg_resources, developers are warned to only "require Gems"
> on things that are *not* imported (preferably in the equivalent of
> our
> console_scripts wrappers). Otherwise you get an unwanted Gem
> dependency if you ever tried to use the same gem outside of the gem
> system.
>
I don't really know what you mean by this - could you please reword it?
--
Regards,
Bohuslav "Slavek" Kabrda.
_______________________________________________
Distutils-SIG maillist - [email protected]
http://mail.python.org/mailman/listinfo/distutils-sig
