Jyri Virkki wrote: > Darren Kenny wrote: >>> Where do these bits end up by default? $HOME, `pwd`, somewhere else? >> By default it will install in <python_home>/site-packages (in our >> case /usr/lib/python2.4/site-packages. If you attempt to do this >> when you don't have permissions, it returns with the error below >> which provides a lot of detail... > > Thanks, that's what I suspected. > > I'm not entirely comfortable with these app-specific packaging > subsystem (this case is one but Ruby w/rubygems is also looking into > the same issue these days) delivering the downloaded content into /usr/... > since /usr can be shared and/or read-only.
Sure, but it can only really install in /usr if the user has such authority to do so, and I think most sys admins are intelligent enough to be aware of issues at this level and take the appropriate action should they prefer not to. Your general "Joe Soap" user will be forced to make a decision on an alternative location that suits their needs. > > I'm not familiar with Python's eazy_install [aside - in debian I see > it's called easy_install, what's the most common version] but Ruby's > 'gems' is an equivalent case. Some distros (at least debian, see > http://pkg-ruby-extras.alioth.debian.org/rubygems.html) set it up to > install into /var/ to avoid those problems I figured that this might arise - the package is called "easy_install", with an "s" instead of a "z" - I think that reflects it's origin in the community. If I have made a mistake in my original case then I apologise, I naturally use an s, but have been known to enter "US mode" inserting a z from time to time. If we were to install into var, then Python itself would also need a change to include /var into it's search path for modules. > > Another detail to think about is if there is any interaction between > the tool (here eazy_install) -installed libraries vs. copies of > possibly the same libraries delivered by Solaris packages in the future > (thinking of the Ruby world again, one can install Rails via gem but there > are also good arguments for delivering it as a package). Do they both > install into the same location under /usr/... and stomp on each other? > That'd be a bad answer ;-) No, the packages we deliver install into /usr/lib/python2.4/vendor-packages, while locally installed modules are installed into /usr/lib/python2.4/site-packages (similar to how Perl behaves). This was addressed in PSARC/2005/555. > > The case should at least consider these topics. > > It'd be even nicer if we can come up with a consistent approach so it > can be applied here and for ruby gems as well as other future projects > which bundle their own app-specific packaging system. > I'm not familiar with how Ruby Gems installs, so I welcome some advice here on how we could share mechanisms. > > >> Hmm, given the above reasoning, maybe the versioned >> easy_install-<PythonVer> is the one that is more likely to be >> Volatile, what do people think? > > Probably not, because the versioned one is the one that can remain > consistent over time. IOW if you have foo-1.0 it can forever be > foo-1.0, no matter how incompatible foo-2.0 may end up being in some > unpredictable future. > > But if you have a link 'foo' -> 'foo-1.0', presumably you'd like to be > able to change it to point elsewhere in the future so its behavior > (i.e. the behavior of what it points to) may change. > OK, so based on this I should make easy_install Volatile, and easy_install-2.4 Uncommitted. Thanks, Darren.
