[Distutils] Parallel installation of incompatible versions

Bohuslav Kabrda bkabrda at redhat.com
Wed Mar 20 14:24:46 CET 2013


----- 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.


More information about the Distutils-SIG mailing list