[Distutils] Setuptools' goal in rpm/deb-based systems
dangoor at gmail.com
Thu Dec 29 16:31:49 CET 2005
On 12/29/05, Jeff Pitman <jeff.pitman at gmail.com> wrote:
> This may have been discussed ad nauseum already, but as I tried to
> package turbogears for Fedora/CentOS, I thought I'd throw in 2 cents.
Hey, great! I'm sure many will appreciate the effort!
> I see that --single-version-externally-managed has been added as an
> option so that .deb/.rpm packaging can take advantage of that relying
> upon apt/yum/smart to take care of business. Hopefully, this will be
> pushed out soon. (Because turbogears script generation is not trivial
> to package. I think I'll just include a generated script as one of the
> Sources, for now.)
Note that TurboGears 0.9 absolutely needs to run as a proper egg.
(When you say you're including the generated script as part of the
sources, I'm not sure if that means that you're bypassing the egg
> I think the goal for setuptools on rpm/deb-based systems should focus
> on getting $HOME setup and managed correctly for packages not provided
> by the system. For example, if I had an ISP which provided python2.4,
> but not TurboGears, then I could use .egg to manage a setup in $HOME
> to use the packages correctly. Currently, -d/-s and other options can
> be used. But, if the user isn't root, maybe it should be the default
> behavior: install and manage in $HOME.
Setting things up in $HOME is definitely a good thing, and doesn't
take very much effort. I hope more ISPs will do so (and it's something
I'm working on with TurboGears hosting providers).
> Also, are there efforts to detect if a package is already installed?
> For example, if "python-sqlobject" is installed, can setuptools detect
> the lib if the install_requires has "SQLObject"? I think peering
> between .egg and .deb/.rpm to be a difficult problem. So, having it
> all or nothing would be a cleaner policy. .deb/.rpm to manage /usr
> installed packages/modules and .egg to manage $HOME installed
The problem is with the missing metadata. setuptools doesn't know what
version of SQLObject that is, and TurboGears most definitely requires
0.7 and up. I think the goal is ultimately to have system-installed
.debs/.rpms that are also eggs (with the proper metadata). TurboGears
0.9 makes use of setuptools' extension mechanism which is why the egg
metadata needs to be available.
More information about the Distutils-SIG